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To  set  the  stage  for  the  course,  ask  your  students  to  write  down  their  answers  to  the  following  questions; 
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DISCUSSION 
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UNIT  1:  SOFTWARE  DEVELOPMENT 

SUMMARY 

Software  development  involves  more  than  just  writing  code. 

Software  Life  Cycle 

•  The  customer  states  the  NEED  for  the  software. 

•  The  developer  DEVELOPS  the  software. 

•  The  software  is  USED,  debugged,  and  enhanced. 

•  The  software  becomes  obsolete  and  is  RETIRED. 


Software  Development  Process 


Requirements 


•  Requirements  define  the  problem. 

•  Since  you  cannot  solve  a  problem  unless  you  know  what  the  problem  is,  defining  the 
requirements  is  the  most  important  step  in  software  development. 


I 


Wrong  or  vague  requirements  cost  money. 
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MEGAPROGRjVMMING 

•  Megaprogramming  is  the  next  generation  in  software  development  processes. 

•  Megaprogramming  looks  at  similar  problems  and  solutions  as  opposed  to  seeing  each  as 
unique. 

•  This  set  of  similar  problems  with  their  solutions  is  called  a  problem  area. 

•  Megaprogramming  takes  advantage  of  the  similarities  and  differences  between  the  problems 
when  generating  a  solution  to  a  specific  problem. 

•  In  the  following  figure,  everything  above  the  dotted  line  defines  problems  and  solutions  within 
the  problem  area.  The  steps  below  the  dotted  line  are  done  to  creat,  a  sfiecific  solution  for 
a  specific  problem  within  that  problem  area. 


Your  Customer 


A  good  analogy  to  megaprogramming  is  the  building  of  computers.  Most  computer  companies  build 
several  types  of  computers — ^for  example,  stationary  and  laptop.  They  don’t  build  all  the  individual 
chips  and  boards  differently.  They  take  existing  parts  and,  based  on  their  knowledge  of  how  to  build 
computers,  assemble  them  in  slightly  different  ways  depending  on  what  they  want  to  produce. 
Software  developers,  on  the  other  hand,  traditionally  generate  software  from  scratch  each  time. 
Megaprogramming  is  an  attempt  to  allow  software  developers  to  do  what  hardware  engineers  do;  use 
existing,  proven  components  each  time  a  product  is  created. 
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UNITl:  SOFTWARE  DEVELOPMENT 

EXERCISES 


Generating  Requirements 

Write  down  all  of  the  information  you  think  you  would  need  to  develop  a  software  program  that  would 
solve  the  following  problems.  Don’t  worry  about  specific  procedures.  List  only  all  of  the  information 
you  would  need  to  solve  the  problem. 

1 .  Beach  Trip  -  You  and  a  friend  want  to  drive  to  the  beach  for  a  weekend  and  you  want  to  know 
(1)  how  long  it  is  going  to  take  and  (2)  how  much  the  gas  is  going  to  cost. 

2.  Scheduler  -  You  want  to  develop  a  program  that  automatically  schedules  all  of  your  activities 
during  the  week.  You  want  to  be  able  to  run  this  program  every  Sunday  so  you  know  the  time, 
date,  and  location  for  each  activity. 

3.  The  Cleaning  Robot  -  With  such  busy  lives  these  days,  you  decide  to  develop  a  robot  that  will 
clean  up  litter  in  a  teenager's  room. 

4.  Several  Robots  -  Suppose  you  work  for  United  Robot  Workers,  Inc.  (URW).  Three 
customers  approach  you.  Each  has  different  needs: 

a.  Customer  1,  a  farmer,  owns  a  large  cornfield  and  has  trouble  finding  time  to  harvest 
it.  She  wants  to  know  if  you  can  provide  a  robot  that  will  harvest  her  corn  without 
human  supervision. 

b.  Customer  2  is  from  the  Alaska  National  Guard,  which  is  constantly  rescuing  people 
who  wander  too  far  afield  in  the  tundra.  Mounting  a  rescue  party  is  time  consuming; 
people  have  died  while  the  members  of  the  party  are  gathering.  The  Guard  thinks 
having  robots  ready  could  eliminate  these  life-threatening  delays. 

c.  Customer  3,  from  the  National  Park  Service,  is  concerned  about  growing  amounts  of 
litter  in  national  parks  and  wants  to  know  if  you  can  provide  a  robot  that  can  pick  up 
the  litter. 

These  three  statements  correspond  to  the  customers’  vague  understandings  of  their  problems 
and  of  potential  solutions.  Your  task  is  to  write  a  set  of  questions  for  each  customer  that  would 
clarify  each  of  the  problems. 

5.  Vending  machines  -  The  Student  Government  Association  (SGA)  has  funds  to  build  a 
vending  machine  room  near  the  central  hall.  The  principal  has  agreed  to  let  the  SGA  go  ahead 
if  they  make  provisions  to  keep  it  attractive  and  litter  free.  It  is  your  job  to  define  the 
requirements  for  the  vending  machine.  Whai  information  do  you  need  to  define  the 
requirements? 

List  the  exact  requirements  for  the  particular  vending  machine  you  were  assigned  in  class.  The 
requirements  you  come  up  with  wilt  most  likely  expand  beyond  the  requirements  identified 
in  the  class  discussion. 


3 


;nt.  Workbook 


Overview  of  Megapfoyamming  Course:  Unit  1,  Software  Dcvelopmc 


Vtis  page  intentionally  left  blank. 


Overview  (rf  Mcgiaprotramming  Course:  Unit  1.  Software  Development,  Workbook 


UNITl;  SOFTWARE  DEVELOPMENT 

TEACHER  NOTES  FOR  EXERCISES 

Here  are  lists  of  needed  information  for  each  of  the  problems.  Each  list  is  probably  not  complete.  Again, 
the  point  of  the  exercise  is  not  to  create  a  comprehensive  list  but  to  make  the  students  realize  how  hard  it 
is  to  generate  a  complete  list. 

Several  of  these  exercises  deal  with  hardware  as  opposed  to  software.  However,  the  course  lecture  material 
focuses  on  software.  The  point  of  the  exercises  for  all  units  is  to  get  across  key  concepts  in  software 
development  and  in  megaprogramming.  We  have  used  examples  in  these  exercises  that  we  feel  will  get  the 
concepts  across  to  the  students  without  worrying  about  whether  or  not  the  example  was  softwe.  r-lated. 

The  first  three  exercises  are  optional.  The  fourth  exercise  begins  the  introduction  of  what  the  students  will 
see  in  the  laboratory.  The  fifth  exercise  is  threaded  into  the  next  day  and  can  be  used  as  homework. 

Genekating  Requirements 

Write  down  all  of  the  information  you  think  you  would  need  to  develop  a  software  program  that  would 
solve  the  following  problems.  Don’t  worry  about  specific  procedures.  List  only  all  of  the  information 
you  would  need  to  write  tf software. 

1 .  Beach  Trip  -  You  and  a  friend  want  to  drive  to  the  beach  for  a  weekend  and  you  want  to  know 

(1)  how  long  it  is  going  to  take  and  (2)  how  much  the  gas  is  going  to  cost. 

•  Cost  of  the  gas 

•  Number  of  miles  to  the  beach 

•  The  speed  limit 

•  How  much  time  it  takes  to  stop  for  gas 

•  How  much  gas  you  have  in  the  tank  when  you  start  the  trip 

•  How  big  your  gas  tank  is 

•  How  many  mUes  per  gallon  your  car  takes 

You  also  have  to  make  certain  assumptions,  such  the  following  (others  might  make  different 
assumptions,  which  would  change  the  program  and  the  answer): 

•  You  always  drive  at  the  speed  limit. 

•  The  only  time  you  stop  is  when  you  stop  to  get  gas. 

•  When  you  stop  for  gas,  you  always  stop  for  the  same  amount  of  time. 

•  There  is  no  traffic. 
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2.  Scheduler  -  You  want  to  develop  a  program  that  automatically  schedules  all  of  your  activities 
during  the  week.  You  want  to  be  able  to  run  this  program  every  Sunday  so  you  know  the  time, 
date,  and  location  for  each  activity. 

•  A  list  of  all  of  the  activities  you  are  involved  in  for  the  week 

-  Those  that  are  flexible  and  can  be  performed  on  any  day  (e.g.,  working  on  your  term  paper) 

-  Those  that  can  only  be  performed  at  certain  times  (e.g.,  when  the  computer  lab  is  available 
for  use) 

•  How  long  each  activity  takes 

•  Whether  there  are  any  activities  that  need  to  be  performed  before  other  activities  can  start  or 
finish  (e.g.,  you  have  to  practice  your  piano  before  your  next  piano  lesson) 

•  What  your  start  time  is  for  the  day 

•  What  your  end  time  is  for  the  day 

•  If  there  is  a  deadline  for  any  of  the  activities  (e.g.,  your  term  paper  is  due  on  Thursday,  so  it  is 
better  not  to  schedule  that  work  for  Friday) 

•  How  you  want  your  schedule  to  be  presented  (e.g.,  so  it  looks  like  a  calendar  or  just  a  list  for 
each  day  followed  by  the  time) 

It  might  be  useful  to  have  a  separate  text  file  to  hold  those  activities  that  occur  every  week. 

3.  The  Cleaning  Robot  -  With  such  busy  lives  these  days,  you  decide  to  develop  a  robot  that  will 
clean  up  litter  in  a  teenager’s  room. 

This  one  is  a  lot  harder  because  each  teenager  has  a  different  room  layout  and  different  types  of 
litter. 

•  How  often  does  the  room  need  to  be  cleaned?  This  will  have  an  impact  on  how  much  litter  there 
is — cleaning  once  a  month  means  more  litter  to  pick  up  than  cleaning  once  a  week. 

•  How  much  litter  is  in  a  typical  teenager's  room  when  it  is  time  to  do  the  cleaning?  This  will  affect 
the  size  of  the  bag  that  the  robot  carries  to  hold  the  litter. 

•  What  distinguishes  litter  from  nonlitter? 

•  What  types  of  litter  are  there?  Is  the  litter  usually  small  (paper,  bottles,  cans,  wrappers)  ormight 
it  be  bigger? 

•  Should  the  robot  discriminate  among  articles  it  picks  up  —  e.g.,  clotheson  the  floor  that  should 
go  into  a  laundry  basket  as  opposed  to  the  trash  can?  Are  there  other  items  tfuit  should  not  go 
into  the  trash  can?  What  should  the  robot  do  with  them? 

•  What  does  a  typical  teenager's  room  look  like  (for  example,  what  kind  of  furniture  is  there)? 
Do  we  need  to  search  on  top  of  each  piece  of  furniture  for  litter  or  can  we  look  just  on  the  floor? 

•  How  much  time  does  the  teenager  etpect  ( or  can  the  teenager  afford)  each  cleaning  to  take? 
This  will  have  a  direct  impact  on  how  fast  the  robot  must  work. 
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Specific  information  you  would  need  for  programming  your  robot  includes: 

•  The  amount  of  energy  the  robot  needs  ( maybe  you  ’ll  be  strapping  battery  packs  on ). 

•  The  size  of  the  bag  your  robot  will  have  for  litter. 

•  How  you  plan  to  make  your  robot  traverse  the  room.  To  do  this,  you  will  need  a  map  of  each 
room  and  a  strategy  for  making  sure  you  cover  all  parts. 

•  How  you  plan  on  getting  at  jund  furniture. 

•  How  you  plan  on  sensing  the  litter  (e.g.,  a  metal  detector)  and  the  range  at  which  your  robot’s 
sensors  can  sense  the  litter  (e.g.,  within  1  ft.,  3  ft.,  etc. ). 

4.  Several  Robots  -  Suppose  you  work  for  United  Robot  Workers,  Inc.  (URW).  Three 
customers  approach  you.  Each  has  different  needs: 

a.  Customer  1,  a  farmer,  owns  a  large  cornfield  and  has  trouble  finding  time  to  harvest 
it.  She  wants  to  know  if  you  can  provide  a  robot  that  will  harvest  her  corn  without 
human  supervision. 

b.  Customer  2  is  from  the  Alaska  National  Guard,  which  is  constantly  rescuing  people 
who  wander  too  far  afield  in  the  tundra.  Mounting  a  rescue  party  is  time  consuming; 
people  have  died  while  the  members  of  the  party  are  gathering.  The  Guard  thinks 
having  robots  ready  could  eliminate  these  life-threatening  delays. 

c.  Customer  3,  from  the  National  Park  Service,  is  concerned  about  growing  amounts  of 
litter  in  national  parks  and  wants  to  know  if  you  can  provide  a  robot  that  can  pick  up 
the  litter. 

These  three  statements  correspond  to  the  customers’  vague  understandings  of  their  problems 
and  of  potential  solutions.  Your  task  is  to  write  a  set  of  questions  for  each  customer  to  clarify 
each  problem. 

This  exercise  leads  up  to  the  laboratory  in  Unit  3.  There, you  will  play  the  role  of  customer.  The  scope 
of  the  problem  area  will  be  restricted  considerably  more  than  it  is  here,  making  the  questions  easier 
to  answer.  The  purpose  of  this  exercise  is  to  get  the  students  thinking  about  robots.  Questions  they 
might  pose  include,  but  are  not  limited  to,  the  following: 

•  How  much  is  the  customer  willing  to  spend? 

•  For  the  Alaska  National  Guard,  what  should  the  robot  do  with  the  people  once  it  finds  them  ? 
Should  it  pick  them  up  and  carry  them  to  safety,  or  should  it  carry  shelter  and  supplies  with  it? 
What  is  an  acceptable  speed  for  the  robot? 

•  How  much  com  (for  the  cornfield  robot)  or  litter  (for  the  National  Park  Service)  should  the 
robot  be  able  to  carry? 

Remember  to  make  students  focus  on  requirements  rather  than  solutions.  They  should  not  ask 
questions  like,  “What  type  of  locomotion  mechanism  do  you  want?’’ or  "What  is  the  maximum 
speed  of the  robot?” As  employees  of  URW,  they  should  already  know  the  answer  to  such  questions. 
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5.  Vending  machines  -  The  Student  Government  Association  (SGA)  has  funds  to  build  a 
vending  machine  room  near  the  central  hall.  The  principal  has  agreed  to  let  the  SGA  go  ahead 
if  they  make  provisions  to  keep  it  attractive  and  litter  free.  It  is  your  job  to  define  the 
requirements  for  the  vending  machine.  What  information  do  you  need  to  define  the 
requirements? 

The  answers  to  this  exercise  will  follow  a  d^erent  format  to  support  classroom  discussion  and  lay 
the  foundation  for  a  homework  exercise  and  lead-in  to  a  Unit  2  exercise. 

It  works  well  to  have  individuals  or  groups  put  their  lists  on  large  sheets  of paper  and  tack  them  to 
the  wall  These  lists  can  then  be  used  in  the  Unit  2  discussion  of  similarities  and  differences. 

Class  Discussion: 

You  need  to  know  the  following  things: 

•  What  kinds  of  items  will  be  sold? 

Generate  a  list  of  possibilities  with  the  students.  The  idea  here  is  to  have  a  variety  of  items. 
The  list  might  include  soft  drinks,  hot  soups,  school  supplies,  snack  crackers,  fruit  juices,  nuts 
and  candies,  sandwiches,  etc. 

•  In  what  price  range  should  the  items  be? 

(There  are  a  lot  more  requirements.  These  are  just  the  first  two  that  will  help  determine  all  of  the 
other  requirements  ) 

Generate  lists  of  possibilities  for  each  question.  Then,  imagine  several  different  vending  machines, 
each  fulfilling  a  different  requirements  set.  Examples: 

—  A  sandwich  machine  that  sells  only  sandwiches  and  chips.  The  sandwiches  may  be  hot  or 
cold. 

-  A  soda  machine  that  sells  by  the  can  or  by  the  cup. 

—  A  snack  machine  that  sells  nuts,  crackers,  candies,  etc. 

—  A  hot  meal  machine  that  sells  soups,  TV  dinners,  etc. 

-  A  supplies  machine  that  sells  pencils,  pens,  paper,  scissors,  folders,  etc. 

Each  one  of  these  vending  machines  will  have  its  own  unique  set  of  requirements.  These 
requirements  might  include  a  thermometer  to  monitor  temperature,  unique  display  requirements, 
varying  input  support  (e.g.,  bills  as  well  as  coins),  size  of  output  bin,  etc 

Come  up  with  exact  requirements  for  the  particular  vending  machine  you  were  assigned  in 
class.  The  requirements  you  come  up  with  will  most  likely  expand  beyond  the  requirements 
identified  in  the  class  discussion. 

Assign  each  student,  or  small  groups  cf  students,  one  of  the  machines  discussed  in  class.  Their 
assignment  is  to  list  exact  reqidrementsfortheirparticularvending  machine.  The  requirements  they 
come  up  with  will  most  likely  expand  beyond  the  requirements  identified  in  the  class  discussion. 
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UNIT  2;  CONCEPTS  OF  MEGAPROGRAMMING 


SUMMARY 

Domains 

•  Domains  contain  related  problems  and  solutions  that  have: 

-  Similarities  among  problems 

-  Solutions  with  common  parts 

-  Variations  among  the  problems  and  solutions 


•  When  defining  domains: 

—  Make  sure  the  problems  and  solutions  have  enough  in  common  that  it  pays  to  consider 
them  together. 

—  Do  not  include  large  numbers  of  barely-related  problems  in  the  same  domain. 

•  When  identifying  a  problem  in  the  domain,  you  only  need  to  identify  how  it  differs  from  other 
problems.  What  is  common  to  all  problems  defines  the  other  characteristics  of  the  problem. 
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•  When  solving  a  problem  in  the  domain,  you  can  make  use  of  what  is  common  to  all  solutions. 


Domain  of  Robots 


Commonalities  of  the 

ftroblems  that  robots  solve 
For  example,  they  all  need  to 
search  for  something.) 

Commonalities  of  robot 
solutions 

(For  example,  they  all  have  a 
face-north  procedure.) 

Differences  among 
individual  robot  problems 
and  among  solutions 

(For  example,  some  robots 
need  special  search 
algorithms  that  will  allow  them 
to  avoid  obstacles.) 


JJ 


Write  code  that  solves  the 
common  parts  of  the  problem  and 
then  reuse  it  in  aii  soiutions. 

(For  example,  the  face-north 
procedure.) 


Write  code  that  implements  the 
differences  among  different 
solutions. 

(For  example,  the  search  procedure 
that  makes  sure  the  robot  avoids 
obstacles.) 


Megaprogramming 
Megaprogramming  has  two  main  tasks: 

1.  Domain  engineering  where  we: 

•  Understand  the  problems  in  a  domain 

•  Determine  the  best  way  to  create  solutions  to  problems  in  that  domain 

•  Create  software  that  is  reusable  in  all  solutions  in  the  domain 

2.  Application  engineering  where  we: 

•  Understand  the  problem  of  a  particular  customer 

•  Create  a  solution  to  an  individual  problem  of  a  customer 

•  Reuse  software  we  have  developed  in  domain  engineering  to  create  our  solutions 
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UNIT  2:  CONCEPTS  OF  MEGAPROGRAMMING 


EXERCISES 

1.  Continue  with  your  vending  machine  problem  (Unit  1,  Problem  5).  On  the  board,  or  on  large 
sheets  of  paper,  list  the  requirements  generated  by  the  students.  Ask  the  following  questions: 

Similarities: 

•  Are  there  any  similarities  among  the  requirements  for  the  different  vending 
machines? 

•  Could  a  manufacturer  design  a  component  for  each  similarity? 

Differences: 

•  What  requirements  are  different  from  vending  machine  to  vending  machine? 

•  How  could  the  differences  be  accommodated?  Could  any  of  the  differences  be  a 
simple  modification  of  an  already  identified  component?  Would  it  be  necessary  to 
build  an  entirely  new  component? 

Based  on  these  components,  what  components  do  you  need  to  come  up  with  for  your  vending 
machine?  This  could  include  similar  components  as  well  as  components  that  are  different 
from  all  other  vending  machines.  You  should  also  identify  which  components  need  to  interact 
with  each  other,  which  components  you  feel  are  reusable  across  other  vending  machines,  and 
which  components  are  unique  to  your  vending  machine. 

Each  group  of  students  working  on  a  particular  vending  machine  should  come  up  with  a  list 
of  components  that  they  need  to  build  that  vending  machine.  Each  group  should  present  its 
Hnal  list  of  vending  machine  components  to  the  class.  For  each  vending  machine,  discuss  the 
following  questions: 

•  Have  they  designed  a  vending  machine? 

•  Were  they  able  to  identify  “reusable”  components  (i.e.,  components  that  could  be 
used  with  little  or  no  modification)? 

•  What  components  did  they  have  to  create  to  handle  requirements  unique  to  their 
vending  machine? 

•  Would  they  consider  vending  machines  a  class  of  common  problems  and  solutions  (a 
domain)? 

•  What  are  some  of  the  benefits  of  going  through  these  steps? 

When  you  are  finished,  answer  the  following  questions: 


•  Could  you  use  megaprogramming  concepts  to  help  build  vending  machines? 

•  What  would  the  domain  engineer  do  in  this  domain? 

•  What  would  an  application  engineer  do  in  this  domain? 

Discuss  the  robot  problem  from  Unit  1,  Problem  4. 

•  Make  a  list  of  common  jobs  and  tasks  that  the  three  robots  in  Unit  1,  Problem  4 
needed. 

•  Make  a  list  of  specific  jobs  and  tasks  that  not  all  the  robots  needed. 

HOMEWORK 

1.  Consider  the  following — are  they  domains?  Why  or  why  not? 

•  The  process  of  applying  to  college 

•  The  process  of  proving  equations 

•  The  process  of  school  bus  scheduling 

•  The  process  of  transportation  scheduling 

2.  Describe  a  domain  in  today's  world  of  teenagers.  List  the  similarities  and  differences  in  your 
domain. 
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UNIT  2:  CONCEPTS  OF  MEGAPROGRAMMING 


TEACHER  NOTES  FOR  EXERCISES 

1.  Continue  with  your  vending  machine  problem  (Unit  1,  Problem  5).  On  the  board,  or  on  large 

sheets  of  paper,  list  the  requirements  generated  by  the  students.  Ask  the  following  questions: 

Similarities: 

•  Are  there  any  similarities  among  the  requirements  for  the  different  vending 
machines? 

Examples  of  similarities  might  include  the  need  for  the  following:  temperature  monitor, 
display,  input,  output,  storage  modules,  etc. 

•  Could  a  manufacturer  design  a  component  for  each  similarity? 

This  should  generate  a  list  such  as  coin  boxes,  mechanisms  to  deliver  the  merchandise, 
display  units,  utilities  units,  storage  units,  housing  units. 

Differences: 

•  What  requirements  are  different  from  vending  machine  to  vending  machine? 

Examples  of  differences  might  include  a  microwave  to  heat  an  item,  a  special  option  that 
makes  change  for  bills,  etc. 

•  How  could  the  differences  be  accommodated?  Could  any  of  the  differences  be  a 
simple  modification  of  an  already  identified  component?  Would  it  be  necessary  to 
build  an  entirely  new  component? 

For  example:  A  microwave  to  heal  an  item  would  probably  have  to  be  a  new  component. 
A  bill  changer  could  probably  be  a  modification  of  the  existing  coinibill  input  mechanism. 

Based  on  these  components,  what  components  do  you  need  to  come  up  with  for  your  vending 
machine?  This  could  include  similar  components  as  well  as  components  that  are  different 
from  all  other  vending  machines.  You  should  also  identify  which  components  need  to  interact 
with  each  other,  which  components  you  feel  are  reusable  across  other  vending  machines,  and 
which  components  are  unique  to  your  vending  machine. 

Assign  a  group  of  students  to  each  of  the  vending  machines  identified  in  the  Unit  1  exercise.  Based 
on  the  components  discussed  today,  have  them  identify  what  components  they  will  need  to  come 
up  with  for  a  complete  veruiing  machine.  This  could  include  simUar  components  as  well  as 
components  that  are  different  from  all  other  vending  machines.  They  should  also  identify  which 
components  need  to  interact  with  each  other,  which  components  they  feel  are  reusable  across  other 
vending  machines,  and  which  components  are  unique  to  this  vending  machine. 

This  can  be  done  either  as  a  homework  assignment  or  as  a  small-group  exercise  at  the  end  of  Unit  2 
or  before  Unit  3. 
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Each  group  of  students  working  on  a  particular  vending  machine  should  come  up  with  a  list 
of  components  that  they  need  to  build  that  vending  machine.  Each  group  should  present  its 
final  list  of  vending  machine  components  to  the  class.  For  each  vending  machine,  discuss  the 
following  questions: 

•  Have  they  designed  a  vending  machine? 

See  if  the  other  students  can  identify  any  missing  components.  The  point  of  this  question 
is  to  help  the  students  see  that,  like  requirements,  making  sure  that  you  have  everything  is 
difficult. 

•  Were  you  able  to  identify  “reusable”  components  (i.e.,  com]X)nents  that  could  be  used 
with  little  or  no  modification)? 

The  students  should  understand  why  having  reusable  components  can  save  time  and 
money.  These  components  can  be  software  programs  or  actual  vending  machine  hardware 
components:  the  idea  of  savings  remains  the  same. 

•  What  components  did  they  have  to  create  to  handle  requirements  unique  to  their 
vending  machine? 

All  solutions  will  have  unique  parts.  If  there  were  no  unique  parts,  then  the  solution  would 
be  exactfy  identical  to  another  problemi solution  and  you  would  only  have  to  build  one 
solu’ion. 

•  Would  they  consider  vending  machines  a  class  of  common  problems  and  solutions  (a 
domain)? 

ifes:  There  are  enough  similarities  to  make  it  worth  your  while  to  understand  the  similarities 
and  differences  among  vending  machines  and  to  make  use  of  that  knowledge  each  time 
you  build  a  new  one. 

•  What  are  some  of  the  benefits  of  this  procedure? 

Savings  in  desi^,  savings  in  manufacturing,  aesthetic  uniformity,  etc 
When  you  are  finished,  answer  the  following  questions: 

•  Could  you  use  megaprogramming  concepts  to  help  build  vending  machines? 

Yes.  There  is  enough  in  common  between  vending  machines,  yet  enough  differences,  that 
it  makes  sense  to  study  their  similarities  and  differences. 

•  What  would  the  domain  engineer  do  in  this  domain? 

The  domain  engineer  would  create  reusable  vending  machine  components  and  documents 
that  describe  how  to  use  those  components  to  build  vending  machines. 

•  What  would  an  application  engineer  do  in  this  domain? 

An  application  engineer  would  talk  to  a  customer  and  use  the  products  created  by  the 
domain  engineers  to  define  and  validate  requirements  that  met  the  customer’s  need,  and 
build  a  vending  machine  that  satisfied  those  requirements. 
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2.  Discuss  the  robot  problem  from  Unit  1,  Problem  4. 

•  Make  a  list  of  common  jobs  and  tasks  that  the  three  robots  in  Unit  1,  Problem  4 
needed. 

•  Make  a  list  of  specific  jobs  and  tasks  that  not  all  the  robots  needed. 

The  answer  to  these  two  questions  depends  on  the  students' answers  to  Problem  4  in  Unit  1. 
However,  they  might  observe  that  all  the  robots  move,  and  they  search  for  some  type  of 
object.  The  type  of  object,  and  the  robot’s  response  to  finding  it,  are  two  things  that  vary 
among  the  three  robots 

TEACHER  NOTES  FOR  HOMEWORK 

1.  Consider  the  following — are  they  domains?  Why  or  why  not? 

•  The  process  of  applying  to  college 

Yes.  Colleges  usually  ask  for  many  similar  types  of  information  on  their  application  forms, 
yet  there  are  enough  differences  that  you  could  not  use  the  same  application  at  more  than 
one  school  without  any  changes 

•  The  process  of  proving  equations 

Yes  You  follow  similar  steps  in  solving  any  equation.  However,  the  order  in  which  you 
foUow  the  steps  and  the  exact  steps  you  follow  will  vary  from  equation  to  equation. 

•  The  process  of  school  bus  scheduling 

Yes.  School  bus  scheduling  will  have  the  same  coordination  and  logistics  problems  from 
school  to  school  and  county  to  county.  However,  there  will  be  enough  differences  (e.g., 
numberof  buses,  size  of  district,  etc)  thalyoucouldnot  use  the  same  school  bus  scheduling 
system  for  every  school 

•  The  process  of  transportation  scheduling 

No.  This  domain  would  be  too  large  to  justify  establishing  a  domain.  There  are  hilarities 
between  different  types  of  transportation;  however,  there  are  too  many  differences  from  one 
transportation  type  to  another  and  not  enough  similarities  that  it  will  not  pay  to  generate 
ami  use  the  domain. 

2.  Describe  a  domain  in  today’s  world  of  teenagers.  List  the  similarities  and  differences  in  your 
domain. 

•  The  answers  for  this  question  will  vary.  Look  for  a  domain  that  has  enough  similarities 
between  the  problems  and  solutions  and  significant  differences  that  it  would  make  sense 
to  establish  and  use  a  domain  whenever  you  need  to  generate  a  solution. 
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UNIT  3:  APPLICATION  ENGINEERING 

SUMMARY 

Application  engineering  involves: 

•  A  customer  who  has  a  problem 

•  An  application  engineer  who  solves  the  problem 
An  application  engineer  solves  the  problem  by: 

1.  Understanding  and  precisely  stating  the  problem  AND 

2.  Generating  a  solution  based  on  the  problem  statement 


Customer’s 

Problem 

Statement 


Step  1: 
Precisely 
State 
Problem 


Step  2: 
Generate 
Solution 


Solution 


Step  1:  Precisely  State  Problem 

To  understand  a  problem,  it  is  easier  if  the  application  engineer  understands  other  related  problems: 

•  What  the  problem  has  in  common  with  other,  similar  problems 

•  How  the  problem  differs  from  these  other,  similar  problems 

An  application  engineer  precisely  states  the  problem  in  terms  of  the  domain  by: 

•  Deciding  how  the  problem  differs  from  other  problems  in  the  domain.  These  decisions  will 
require  engineering  judgment  in  addition  to  cold,  hard  facts. 

•  Validating  the  problem  statement  (i.c.,  the  requirements)  to  make  sure  they  precisely  express 
the  behavior  the  customer  intended. 

The  following  decision  trees  show  part  of  the  decisions  needed  to  identify  how  problems  differ  in  the 
automobile  and  robot  domains. 
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Example  Decision  Trees  for  Precisely  Stating  the  Problem 


Step  2:  Generate  Solution 

The  application  engineer  then  generates  a  solution  based  on  the  precise  problem  statement  from 
Step  1.  To  do  this,  the  application  engineer  uses  the  application  engineering  environment  set  up  by 
the  domain  engineer.  This  environment  contains; 

•  Software  components  needed  to  generate  a  solution  to  a  problem  in  the  domain.  These 
components  include: 

-  Components  that  are  common  to  all  solutions 

-  Components  that  solve  only  specific  problems 

•  Help  for  how  to  put  all  of  these  components  together  to  form  a  solution. 

The  following  figure  represents  what  happens  in  the  two  steps  of  application  engineering. 
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UNIT  3:  APPLICATION  ENGINEERING 
LABORATORY 


PART  1:  BACKGROUND 

In  this  laboratory,  you  will  practice  application  engineering.  Imagine  yourself  to  be  an  application 
engineer  who  works  for  URW.  Three  customers  approach  you.  Each  has  different  needs: 

1.  Customer  1,  a  farmer,  owns  a  large  cornfield  and  has  trouble  finding  time  to  harvest  it.  She 
wants  to  know  if  you  can  provide  a  robot  that  will  harvest  her  corn  without  human  supervision. 

2.  Customer  2  is  from  the  Alaska  National  Guard,  which  is  constantly  rescuing  people  who 
wander  too  far  afield  in  the  tundra.  Mounting  a  rescue  party  is  time-consuming;  people  have 
died  while  the  members  of  the  party  were  gathering.  The  Guard  thinks  having  robots  ready 
could  eliminate  these  life-threatening  delays. 

3.  Customer  3,  from  the  National  Park  Service,  is  concerned  about  growing  amounts  of  litter  in 
national  parks,  and  wants  to  know  if  you  can  provide  a  robot  that  can  pick  up  the  litter. 

These  three  statements  correspond  to  customers’  vague  understandings  of  their  problems  and  of 
potential  solutions.  Your  task  in  this  laboratory  is  to  help  these  customers  understand  their  problems 
fully  and  to  provide  them  with  robots  that  solve  their  problems.  To  assist  you  in  this,  we  have  provided 
you  with  a  tool  that  automates  some  of  the  application  engineering.  Part  2  describes  its  use. 

In  brief,  you  will  be  asked  to  generate  the  software  for  a  robot.  You  will  do  so  by  following  the 
application  engineering  process  for  precisely  stating  a  problem,  which  you  saw  in  class.  Some  of  the 
decisions  you  must  make  can  be  answered  from  the  three  statements  above.  Others  may  require 
clarification  from  your  customer.  Your  instructor  will  act  as  the  customer,  answering  questions  you 
might  have  on  the  requirements  for  the  robot.  Keep  in  mind,  though,  that  a  customer  does  not 
necessarily  know  everything.  As  an  application  engineer,  you  are  expected  to  use  your  own  expert 
judgment  when  your  customer  does  not  know  what  choice  is  right. 

PART  2:  EXERCISES 


1.  CoRNHELD  Robot 

URW  manufactures  robots  that  can  harvest  corn.  You  must  act  as  an  application  engineer  and  help 
solve  your  customer’s  problem  by  resolving  the  decisions  in  the  domain.  By  doing  so,  you  will  create 
a  model  of  a  robot  that  harvests  corn.  You  can  use  this  model  to  generate  the  software  that  controls 
the  robot.  However,  you  cannot  just  generate  any  corn-harvesting  robot.  In  the  first  place,  your 
customer  has  a  specific  requirement:  she  wants  the  robot  to  end  its  mission  at  its  point  of  origin.  In 
the  second  place,  she  cannot  spend  more  than  $13,500.00.  The  robot  you  model  must  not  exceed  this 
priee.  Better  still,  it  must  be  the  least  expensive  robot  that  ean  do  the  job. 

You  will  be  informed  of  the  robot’s  price  as  part  of  validation.  However,  you  should  know  that  two 
factors  determine  a  corn-harvesting  robot’s  price.  The  first  factor  is  the  maximum  number  of  ears  of 
corn  it  can  carry.  URW  offers  its  customers  robots  that  carry  between  50  and  500  ears,  in  multiples 
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of  10.  (The  decision  to  carry  53  ears  therefore  results  in  a  K.oot  that  costs  the  same  as  one  that  carries 
60  ears,  although  the  former  robot  will  still  pick  up,  at  most,  53  ears.) 

The  second  factor  is  the  number  of  batteries  with  which  the  robot  is  equipped.  All  robots  have  at  least 
one  battery.  Each  extra  battery  costs  money,  but  increases  the  distance  the  robot  can  travel.  To 
estimate  the  minimum  number  of  batteries  needed,  press  the  F 1  key  when  you  are  asked  to  make  the 
decision  on  the  number  of  batteries. 

Question  A.  Find  the  most  appropriate  robot  for  your  customer.  Do  so  by  repeating  the  process  of 
precisely  stating  the  problem,  varying  the  decisions  until  you  believe  your  model  of  robot  is  right.  Use 
the  following  graph  to  correlate  the  cost  of  each  robot  to  its  carrying  capacity.  What  trend  do  you 
observe? 


Carrying  Capacity  of  Robot 


Question  B.  Generate  and  execute  the  sofovare  for  three  robots:  the  one  you  de.scribed  in  Part  A,  the 
one  with  the  minimum  carrying  capacity,  and  the  one  with  the  maximum  carrying  capacity.  Record  the 
time  needed  for  each  one  to  execute.  Which  takes  the  least  time?  Would  you  have  created  a  different 
robot  for  your  customer  if  time  for  harvesting  had  been  her  highest  priority? 

2.  Rescuing  Robot 

Generate  a  robot  that  meets  the  needs  of  your  second  customer.  What  decisions  related  to  choosing 
the  mission  are  clearly  invalid?  Why? 

Run  your  robot  several  times.  Notice  that  there  is  more  than  one  tundra  for  your  robot  to  search. 
Compare  their  characteristics.  Which  one  requires  more  energy?  Would  you  recommend  that  your 
customer  equip  his  robot  with  enough  batteries  to  handle  either  case,  or  do  you  think  your  customer 
would  be  satisfied  with  a  less  expensive  robot  that  could  only  handle  the  low-energy  case? 
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3.  Litter-Gathehing  Robot 

Generate  a  robot  that  meets  the  needs  of  your  third  customer.  For  this  customer,  you  will  find  that 
you  need  to  try  more  than  one  robot  to  determine  which  one  is  best.  The  reason  is  that  URW  has  two 
searching  strategies  for  robots  that  operate  in  a  forest.  One  is  to  “sweep”  back  and  forth,  horizontally; 
the  other  is  to  zigzag.  Which  is  more  effective  depends  on  the  forest  in  which  the  robot  is  operating. 

Precisely  state  the  problem  for  this  robot.  Use  the  results  to  fill  in  the  following  table: 


Density  of 
IVees  in  Forest 

Cost  of  Robot 

Search  by  Sweeping 

Search  by  Zigzagging 

sparse 

average 

dense 

What  do  you  observe  about  robot  cost  versus  forest  density? 
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PART  3:  USING  THE  APPLICATION  ENGINEERING  ENVIRONMENT 

This  part  of  the  laboratory  desaibes  how  to  use  the  application  engineering  environment  for 
speci^ng  and  generating  robot  software.  Your  instructor  will  tell  you  how  to  invoke  the  environment. 
Once  you  have  done  so,  you  will  see  the  following  menu  (the  main  menu): 

APPLICATION  ENGINEERING  FVVTRONMENT 
FOR 

ROBOT  DOM. 

1 )  Precisely  State  Problem 

2)  Generate  Solution 

3)  Execute  Solution 

4)  View  Generated  Software 

Select  an  item: 

You  will  follow  the  application  engineering  process  by  selecting  each  of  the  first  three  menu  items,  in 
the  order  listed.  Item  1  assists  you  in  precisely  stating  the  customer’s  problem — that  is,  decision 
making  and  validating  the  problem  statement.  Item  2  generates  a  solution  based  on  your  statement 
of  the  problem.  Item  3  allows  you  to  simulate  execution  of  a  robot,  using  a  modified  version  of  the 
Karel  executor  program  (please  note  that  the  programs  you  generate  will  not  work  with  the  Karel 
compiler  or  executor  you  have  used  previously).  Item  4  lets  you  see  the  software  you  generate  using 
Item  2. 

To  select  a  menu  item,  type  the  number  of  the  item,  followed  by  the  ENTER  key.  If  you  need  help,  press 
the  FI  key.  You  can  use  the  backspace  key  to  remove  the  last  character  you  typed.  When  you  are 
finished,  press  the  F2  key  to  exit.  (These  statements  apply  throughout  the  application  engineering 
environment.) 

Precisely  Stating  the  Problem 

Selecting  Item  1  from  the  main  menu  gives  you  the  following  menu: 

PRECISELY  STATE  PROBLEM 
FOR 

ROBOT  DOMAIN 

1 )  Make  Decisions 

2)  Validate  Statement  of  Problem 

Choose  a  step: 

Use  this  menu  to  make  the  decisions  needed  to  identify  a  robot  that  meets  a  customer’s  needs  (Item  1) 
and  to  validate  the  decisions  you  have  made  (Item  2).  Once  you  have  performed  these  two  steps,  press 
F2  to  return  to  the  main  menu. 

Making  Decisions 

Selecting  Item  1  from  the  menu  for  precisely  stating  problems  lets  you  step  through  the 
decision-making  portion  of  the  application  engineering  process  shown  in  class: 


8 


Ovcivicw  of  Megapfogramming  Course:  Unit  3,  Application  F-ngineering.  Laboratory 


You  will  be  presented  with  a  screen  divided  into  three  windows.  The  upper  left  window  shows  the 
decision  you  are  making  and  the  values  you  can  choose  for  that  decision.  The  upper  right  window 
shows  all  decisions,  including  the  values  of  those  you  have  made  so  far.  Each  time  you  make  a  decision, 
you  will  see  the  implications  of  that  decision  in  the  lower  right  window. 

You  will  make  the  decisions  in  the  order  shown  in  the  picture.  In  most  cases,  you  will  be  given  a  menu 
and  asked  to  choose  an  item.  Enter  the  number  of  the  item.  For  Decision  5,  you  will  be  asked  a 
yes-or-no  question;  give  the  full  word  as  an  answer,  not  just  Y  or  N.  For  Decisions  7  and  8,  you  will 
be  asked  to  enter  an  integer  value.  Remember  to  follow  your  answer  by  pressing  the  ENTER  key.  When 
you  have  made  all  the  decisions  and  think  they  meet  your  customer’s  requirements,  press  the  F2  key. 
You  will  return  to  the  main  menu. 

You  can  abort  the  decision-making  process  ,/  pressing  the  ESC  key.  If  you  abort  the  decision-making 
process,  you  must  make  all  the  decisions  again. 

You  can  use  the  up  and  down  arrow  ke5fs  to  move  among  the  decisions.  You  can  use  this  feature  to 
examine  subsequent  decisions  you  must  make  or  to  change  a  decision  you  have  made.  Keep  in  mind 
that  you  must  always  make  decisions  in  the  order  shown  on  the  screen  in  the  upper-left  window.  If  you 
change  a  dedsion,  all  decisions  following  it  need  to  be  made,  even  if  you  already  made  them. 

Each  time  you  make  a  decision,  you  will  be  shown  the  implications  of  that  decision.  These  implications 
are  presented  in  terms  of  how  they  affect  the  robot’s  hardware  and  software.  You  can  feel  free  to 
experiment  with  different  combinations  of  decisions.  You  should  be  able  to  see  how  different  customer 
needs  result  in  different  robots. 

When  you  make  Dedsion  8,  you  will  probably  need  help  estimating  how  many  batteries  your  robot 
will  require.  Press  the  Fl  key,  and  you  will  be  shown  some  values.  Bear  in  mind  that  these  are 
estimates.  Depending  on  the  nuances  of  the  terrain  in  which  your  robot  operates — specifically,  the 
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distribution  of  objects  and  obstacles — your  robot  may  actually  need  more  or  less  energy  for  a 
particular  mission.  Keep  in  mind  the  consequences  of  failure  as  you  choose  the  number  of  batteries. 
A  robot  that  runs  out  of  energy  before  picking  up  all  litter  is  a  nuisance.  A  robot  that  runs  out  of  energy 
before  reaching  a  stranded  party  of  hikers  can  have  tragic  consequences. 

Vaudation 

Once  you  have  made  all  decisions,  you  are  ready  to  validate  your  problem  statement.  In  fact,  much 
of  the  validation  is  already  done.  During  decision  making,  you  could  not  state  a  carrying  capacity  for 
a  robot  that  does  not  pick  up  objects — the  application  engineering  environment  will  not  allow  it. 

However,  you  might  still  have  made  mistakes.  For  example,  you  could  have  misunderstood  your 
customer’s  requirements  and  how  they  relate  to  the  decisions.  During  validation,  you  are  asked  to 
review  the  decisions  you  have  made.  This  is  the  time  when  you  should  make  sure  they  are  proper.  To 
validate  your  decisions,  select  Item  2  from  the  Precisely  State  Problem  menu. 

During  validation,  you  are  also  told  how  much  the  robot  will  cost.  Unless  your  customer  has  a  very 
deep  wallet,  you  should  check  to  make  sure  that  the  robot’s  price  is  within  the  customer’s  range. 

If  you  decide  that  your  decisions  are  impropier,  you  can  easily  revise  them.  Exi  t  validation,  and  choose 
Item  2  (Make  Decisions)  again.  This  time,  you  will  see  the  decisions  you  made  previously  rather  than 
a  set  of  decisions  waiting  to  be  made.  You  can  use  the  down-arrow  key  to  move  directly  to  the 
decision(s)  you  want  to  chang  x 

When  you  think  you  have  a  valid  set  of  decisions,  press  F2  when  you  see  the  Precisely  State  Problem 
menu  displayed.  This  will  return  you  to  the  main  menu. 

Generating  a  Solution 

Once  you  are  satisfied  with  your  statement  of  the  problem,  you  can  generate  a  solution  to  it.  Just  select 
Item  2  from  the  main  menu.  The  program  will  choose  all  the  correa  parts  for  your  solution  and 
assemble  them  into  a  working  program,  which  it  will  then  compile  for  you.  If  you  would  like  to  examine 
the  software  you  generated,  select  Item  4  from  the  main  menu.  You  are  now  ready  to  simulate  the 
execution  of  your  robot. 

Simulating  Execution 

Choose  menu  Item  3  from  the  main  menu.  This  invokes  the  modified  Karel  executor  mentioned 
earlier.  Unlike  the  simulator  you  may  have  used,  the  program  to  execute  and  the  map  are  chosen  for 
you  automatically.  (After  all,  you  wouldn’t  want  to  run  a  robot  meant  for  a  cornfield  through  a  forest! ) 

Prior  to  execution,  you  will  be  presented  with  a  set  of  questions  that  control  how  much  information 
you  see  during  execution.  Be  aware  that  this  information,  although  interesting,  can  add  up  to  IS 
minutes  to  execution  time.  Moreover,  you  do  not  need  it  to  complete  the  laboratory.  You  should  opt 
not  to  display  it  if  you  are  pressed  for  time. 
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UNIT  3:  APPLICATION  ENGINEERING 
LABORATORY 


TEACHER  NOTES  FOR  LABORATORY 

Comment:  This  laboratory  lets  students  use  an  application  engineering  environment.  The 
environment  implements  the  application  engineering  process  for  the  robot  domain  covered  in  the 
Unit  3  lecture. 

The  environment  plays  down  the  role  of  programming.  Students  create  programs,  but  not  as  they  have 
previously.  Instead,  the  environment  automatically  creates  the  software  based  on  a  problem 
statement  the  student  provides.  Theoretically,  students  can  perform  this  laboratory  without  ever 
seeing  any  software.  The  environment  contains  a  tool  that  lets  them  do  so;  this  emphasizes  that 
software  is  necessary  to  the  robot  but  that  it  can  be  developed  in  more  than  one  way. 

What  substitutes  for  programming  is: 

•  Eliciting  and  understanding  customer  requirements  and  elaborating  them  in  terms  of  the 
domain  problem  space.  The  result  is  a  precise  problem  statement. 

•  Quantitative  and  qualitative  analysis  of  requirements  to  determine  satisfaction  of  customer 
needs. 

•  Simulation  as  a  means  to  validate  customer  requirements. 

The  second  item  is  most  significant  and  probably  less  intuitive  to  students  than  the  others.  Students 
are  asked  to  study  problems  and  certain  properdes  of  solutions  purely  in  t;rms  of  domain  problem 
space  concepts.  They  ure  not  allowed  to  think  in  terms  of  primitive  Karel  instruction.!  or  even 
algorithms.  Tliey  must  av't  as  application  engineers,  not  programmers.  By  having  them  do  so,  you  can 
demonstrate  to  them  that  programriung  is  only  a  means  to  an  end,  not  an  end  in  itself. 

1.  Cornfield  Robot 

Answer  to  Question  A:  This  question  asks  the  student  to  analyze  a  problem  without  first  trying  to 
generate  a  solution  to  that  problem.  The  application  engineering  environment  presents  all  the 
information  the  student  needs.  The  student  must  first  precisely  state  the  problem,  selecting  “field” 
as  the  terrain;  this  fixes  the  decisions  on  search  strategy  and  object  type  and  obviates  the  decision  on 
forest  density.  If  any  students  wonder  why,  you  can  explain  it  to  them  as  decisions  already  made  by 
the  domain  engineers: 

•  In  fields,  URW  only  knows  how  to  build  robots  that  harvest  corn.  It  doesn’t  possess  the 
technology  to  build  robots  that  mechanically  harvest,  for  example,  tomatoes. 

•  The  domain  engineers’  studies  have  concluded  that  sweeping  is  a  more  efficient  strategy  than 
zigzagging  when  harvesting  corn.  (Real  harvesting  machines  work  this  way.) 

The  student  must  choose  the  mo't  appropriate  robot.  The  assignment  defines  this  as  the  robot  that 
costs  least,  but  can  still  perform  its  mission.  Since  carrying  capacity  and  number  of  batteries  are  the 
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two  factors  that  determine  a  robot’s  cost,  the  student  must  experiment  with  variations  of  these 
quantities  to  complete  the  assignment.  The  students  will  simply  have  to  try  several  values  of  carrying 
capacity.  They  can  determine  the  number  of  batteries  through  the  help  facility  (available  by  pressing 
the  FI  key).  During  validation,  they  can  obtain  the  cost  of  the  robot  they  have  modeled.  Using  this 
information,  they  should  create  a  graph  similar  to  the  following: 


Carrying  Capacity  of  Robot  (Ears  of  Corn) 


Inform  the  students  that  they  will  need  some  strategy  for  choosing  carrying  capacities,  unless  they  are 
so  motivated  as  to  try  all  451  possible  values.  Note  the  trend  of  cost  increasing  as  a  function  of  carrying 
capacity.  This  should  motivate  them  to  try  a  binary  search  strategy.  Binary  search  by  itself  is  not 
adequate,  because  the  robot’s  cost  does  not  increase  monotonicaliy  as  a  function  of  carrying  capacity, 
but  it  is  a  good  start. 

For  this  mission,  the  robot  costs  least  when  ic-  carrying  capacity  is  60.  Here  is  the  reason  why.  In  the 
cornfield,  each  location  contains  one  ear  of  corn.  Therefore,  each  row  has  30  ears.  Any  multiple  of 
60  minimizes  the  number  of  spaces  a  ,-obot  m-ast  move  to  unload  its  cargo  and  return  to  continue 
harvesting,  since  it  always  fills  its  bag  wht  i\  n  is  against  the  western  border.  A  value  that  is  not  a 
multiple  of  60  would  require  the  robot  to  move  west  as  well  as  south  as  it  returns.  Each  move  consumes 
battery  power,  necessitating  extra  energy;  since  multiples  of  60  minimize  moves,  they  are  preferred. 
Note  that  the  robot  will  make  fewer  moves  if  its  carrying  capacity  is  120  instead  of  60,  and  indeed  will 
make  the  fewest  moves  if  its  carrying  capacity  is 449  (the  number  ofearsofcorninthefield).  However, 
extra  carrying  capacity  costs  money,  and  carrying  400-plus  ears  increases  the  robot’s  weight  enough 
to  cause  it  to  consume  energy  rapidly.  This  in  turn  requires  extra  batteries,  driving  up  the  robot’s  price. 
For  these  reasons,  60  is  the  optimal  carrying  capacity. 

This  fact — that  robots  in  cornfields  behave  best  when  their  carrying  capacity  is  a  multiple  of  60 — is 
an  excellent  example  of  the  type  of  knowledge  possessed  by  experts  in  a  domain.  That  is,  it  is  something 
an  application  engineer  would  know  and  would  automatically  apply  when  approached  by  a  customer. 
This  knowledge  would  be  gained  by  experience,  through  trial  and  error.  Deriving  it  mathematically 
is  difficult;  in  many  domains,  it  is  impossible.  Eventually,  application  engineers  feed  this  type  of 
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trial-and-error  experience  back  into  domain  engineering,  where  experts  incorporate  it  as  a  heuristic 
in  the  application  engineering  environment. 

You  can  discuss  this  with  students.  Ask  them  for  commonplace  but  significant  knowledge  in  other 
domains.  A  few  examples:  does  your  automobile  owner’s  manual  tell  you  how  to  park  your  car?  Few 
do;  of  those  that  do,  do  any  tell  you  to  put  money  in  the  parking  meter?  Does  your  owner’s  manual 
say  to  turn  off  your  ignition  after  you  park  your  car? 

Answer  to  Question  B:  The  following  are  some  sample  results: 


Carrying  Capacity 
(Ears  of  Com) 

Execution  Time 
(Seconds) 

50 

1:00.25 

60 

46.14 

500 

33.84 

These  numbers  were  obtained  running  the  Karel  simulator  on  a  486-based  computer.  The  numbers 
you  obtain  will  depend  upon  the  computer  you  use.  However,  you  should  still  obtain  the  same 
ordering:  a  carrying  capacity  of  SO  results  in  the  slowest  execution  time,  and  a  capacity  of  SOO  results 
in  the  fastest.  Therefore,  if  your  customer  wants  a  robot  that  can  harvest  corn  as  quickly  as  possible, 
and  if  money  is  no  object  to  her,  you  should  recommend  that  she  choose  the  robot  with  the  greatest 
carrying  capacity.  The  most  alert  student  will  also  observe  that,  as  a  field  contains  at  most  449  ears 
of  corn,  the  customer  could  save  a  little  money  without  saaificing  execution  speed  by  buying  a  robot 
whose  carrying  capacity  is  449  or  450  (both  these  robots  cost  the  same). 

To  obtain  consistency  in  the  results,  the  students’  answers  to  the  questions  asked  by  the  simulator  must 
be  identical  for  all  three  trials.  Be  aware  that  the  executor  can  run  very,  very  slowly.  It  is  usually  best 
to  answer  N  to  the  three  yes/no  questions  (see  Simulating  Execution  on  page  10),  and  to  set  the  speed 
to  0.  You  can  use  this  as  an  opportunity  to  reenforce  experimental  science  concepts  to  your  students. 

You  are  not  actually  running  a  robot;  you  are  running  a  simulation.  If  URW  were  a  real  company,  the 
application  engineer  would  run  a  simulation  such  as  this  to  learn  facts  about  the  robot’s  performance 
that  cannot  be  determined  in  other  ways  (i.e.,  as  part  of  validation).  This  point  is  well-illustrated  in 
laboratory  Questions  2  and  3,  with  their  somewhat  randomly-placed  objects  and  obstacles.  Addressing 
the  issues  raised  by  Questions  2  and  3  by  deriving  formulas  is  very  hard.  Simulation  provides  a  simpler 
alternative. 

2.  Rescuing  Robot 

Answer:  There  is  no  point  in  deciding  that  a  robot  should  pick  up  hikers  and  continue  until  it  runs  out 
of  energy.  The  purpose  of  a  “rescue”  mission  would  be  either  to  transport  the  hikers  to  a  safe,  known 
place  (either  the  origin  or  the  point  where  the  entire  terrain  has  been  covered — ^both  can  be  predicted) 
or  to  stay  with  the  hikers  until  help  arrives.  If  the  robot  continued  until  it  ran  out  of  energy,  the 
National  Guard  would  have  difficulty  locating  it,  so  the  hikers  would  be  no  better  off  than  if  they  had 
just  stayed  where  they  were. 

This  laboratory  comes  with  two  maps  of  a  tundra.  One,  named  tundral,  is  intended  to  illustrate  the 
average  case.  A  group  of  three  hikers  is  stranded  more  or  less  in  the  middle.  The  other  map,  named 
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tundra2,  illustrates  the  worst  case.  There  are  a  total  of  five  hikers  (the  maximum  permissible  carrying 
capacity).  Four  are  right  at  the  beginning  of  the  robot’s  search.  The  remaining  hiker  is  at  the  very  end. 
Suppose  you  opt  to  have  the  robot  pick  up  hikers  and  return.  The  robot  will  consume  the  maximum 
possible  amount  of  energy.  It  must  carry  four  hikers  the  greatest  possible  distance  before  it  completes 
its  search  by  finding  the  fifth.  Since  carrying  an  object  consumes  energy,  the  robot’s  energy  use  is 
maximized. 

Choosing  instead  to  have  the  robot  stop  when  it  locates  a  person  creates  a  robot  that  is  probably 
unsatisfactory.  It  will  find  onegroupof  hikers  but  not  the  other.  This  is  not  likely  to  please  the  National 
Guard,  nor  is  a  robot  with  a  carrying  capacity  so  small  that  it  returns  before  it  finds  everyone. 

The  purpose  of  this  question,  then,  is  to  make  sure  the  students  study  the  problem  carefully  and  truly 
understand  the  needs  of  their  customer.  They  must  pay  particular  attention  to  the  following; 

•  Only  certain  combinations  of  ending  location  and  carrying  capability  are  useful  for  rescuing 
people. 

•  The  robot  must  not  run  out  of  energy.  In  a  cornfield,  the  consequences  of  doing  so  are 
annoying.  In  a  tundra,  human  lives  are  at  stake.  Failure  has  dire  consequences. 

•  Application  engineers  must  make  important  choices  based  on  their  own  judgement.  The 
application  engineering  environment  cannot  calculate  the  right  amount  of  energy.  It  can 
predict  average  use  (note  that  the  robot  will  actually  fail  if  given  the  average  number  of 
batteries  needed:  the  hikers  are  just  a  bit  beyond  the  midpoint,  which  is  assumed  to  be 
average),  and  it  can  predict  worst-case  use.  The  worst-case  robot  works  but  is  very  expensive. 
Most  customers  are  not  willing  to  pay  the  price  on  the  off-chance  that  the  worst  case  will  occur. 
They  want  something  that  handles  most  cases.  The  application  engineer  has  the  moral 
responsibility  to  present  this  information  to  the  customer  and  to  tty  to  come  up  with  the  best 
energy  statement.  In  the  laboratory,  you  might  want  to  act  as  customer  and  establish  an 
arbitrary  price  ceiling  that  precludes  building  the  worst-case  robot.  As  part  of  the  assignment, 
ask  the  students  to  prepare  a  report  of  what  they  expect  the  robot  can  do. 

One  note:  the  simulator  chooses  one  of  the  two  maps  used  at  random.  In  a  class  of  20  people,  you  can 
be  95%  confident  that  at  least  one  person  will  not  see  both  maps  even  if  everyone  runs  the  simulation 
4  times.  Be  prepared  to  ask  students  to  keep  running  the  simulator  until  they  have  used  both  maps. 
(The  simulator  shows  the  map’s  name  in  the  lower  left  window.) 

3.  Litter-Gathering  Robot 

Answer  The  following  table  was  created  using  a  carrying  capacity  of  250,  with  the  robot  picking  up 
litter  and  returning  to  its  point  of  origin  when  its  bag  is  full.  The  average-case  number  of  batteries  was 
used.  Such  a  robot  does  not  have  enough  energy  to  complete  is  mission,  but  the  general  trend 
illustrated  by  the  table  does  not  change  with  the  number  of  batteries. 


Density  of 
Ibees  in  Forest 

Cost  of  Robot 

Search  by  Sweeping 

Search  by  Zigzagging 

sparse 

$9,944.00 

$11,806.00 

average 

$10,368.00 

$11,673.00 

dense 

$10,875.00 

$11,540.00 

r 
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Notice  the  difference  between  the  columns.  The  cost  of  a  robot  that  sweeps  is  proportional  to  the 
forest  density.  The  cost  of  a  robot  that  zigzags  is  inversely  proportional  to  forest  density.  If  you 
examine  the  code,  you  will  observe  that  navigating  around  a  tree  in  a  sweep  requires  two  extra  moves 
and  eight  extra  turns.  By  contrast,  zigzagging  around  a  tree  requires  four  fewer  turns  than  if  the  tree 
were  not  present.  In  theory,  then,  a  robot  moving  in  an  extremely  dense  forest  (or  a  larger  one)  would 
do  better  to  zigzag.  In  practice,  a  Karel  map  cannot  contain  enough  trees  to  make  this  worthwhile. 
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UNIT  4:  DOMAIN  ENGINEERING 

SUMMARY 

Domain  engineers  are  responsible  for  building  what  the  application  engineers  need  to  develop 
solutions.  This  includes: 

•  Defining  what  is  in  the  domain 

•  Defining  the  process  that  the  application  engineer  will  follow 

•  Developing  process  support  (including  reusable  components)  that  the  application  engineer 
will  use  to  state  the  problem,  validate  it,  and  generate  the  solution 


Stepi: 

Precisely 

step  2: 
Generate 

olaie 

Problem 

Solution 

Defining  the  Domain 


This  is  the  “biack  box” 
support  that  the  domain 
engineers  create  tor  the 
appiication  engineers. 


Domain  engineers  decide  what  is  in  a  domain. 

Application  engineers  create  individual  systems.  Domain  engineers  decide  the  range  of  systems 
application  engineers  can  create. 

Deciding  what  is  in  a  domain  involves  studying  the  factors  that  constrain  the  problems  and  solutions 
which  form  the  domain  and  deciding  what  problems  and  solutions  are  important. 

Once  the  domain  engineers  know  the  problems  that  will  be  in  the  domain,  they  can  study  them  and 
uncover; 


•  The  commonalities  among  all  problems 

•  The  differences  between  instances  of  problems 


Dehning  the  Process 

An  application  engineer  needs  to  know  what  steps  to  follow  in  order  to  develop  a  solution. 
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Domain  engineers  define  the  process  for  generating  a  solution  in  the  domain  and  develop  process 
support  programs  to  help  the  application  engineer.  These  support  programs  include: 

•  Support  for  defining  and  validating  the  requirements  for  the  solution 

•  Support  for  generating  the  solution 

Architectures 

Every  software  solution  is  composed  of  components  (e.g.,  procedures  and  functions).  Every  software 
solution  has  an  architecture,  which  defines  how  the  components  work  together. 

Domain  engineers  create  a  “domain  architecture”  that: 

•  Defines  the  complete  set  of  components  used  by  all  solutions  in  the  domain 

•  Shows  what  components  and  interrelationships  all  solutions  have  in  common 

•  Shows  how  individual  solutions  differ. 

The  following  figure  shows  the  domain  architecture  for  the  robot  domain. 


Key: 

I  I  Always  present  I _ J  Sometimes  present 


X  calls  Y  in  all  programs 
X  calls  Y  in  some  programs 


Domain  engineers  create  these  compxrnents.  They  also  identify  which  components  are  common  to  all 
solutions  in  the  domain  and  which  are  needed  to  solve  specific  problems. 
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UNIT  4:  DOMAIN  ENGINEERING 


IN-CLASS  DISCUSSION 


1.  Compare  results  of  the  laboratory  activity.  Is  there  more  than  one  robot  software  architecture 
that  satisfies  the  needs  of  each  client?  Why  or  why  not? 

2.  What  other  kinds  of  robots  could  be  produced  by  the  URW,  domain? 


HOMEWORK 

1.  Considering  the  domain  of  the  URW,  would  you,  as  Chairman  of  the  Board,  want  to  produce 
robots  to: 

a.  Plant  corn 

b.  Pick  water  lilies 

c.  Feed  incubator  babies 

In  making  your  decision,  are  there  enough  similarities  to  warrant  asking  your  domain 
engineers  to  write  additional  instructions? 

2.  The  instructions  in  the  left  column  were  used  to  implement  the  software  for  a  robot  that 
searches  a  tundra  for  lost  hikers.  Each  instruction  in  the  left  column  is  an  adaptation  of  an 
architectural  part  in  the  right  column.  Match  each  instruction  in  the  left  column  with  the 
architectural  part  in  the  right  column. 


Instructions 


Architectural  Parts 


1 .  Advance-north-moving-east-to-avoid-rocks- 
returning-when-bag-full 

Move  north  one  unit.  If  a  rock  blocks  the 
path,  move  east  around  it.  If  a  hiker  is 
found,  pick  him  or  her  up;  if  doing  so  brings 
the  robot  to  its  full  capacity,  quit  this  instruction. 


A.  Perform  Mission 

B.  Navigate  Terrain 

C.  Negotiate  Obstacle 

D.  Handle  Object 

E.  Terminate  Mission 


2.  Advance-north-moving-west-to-avoid-rocks- 
returning-when-bag-full 


Same  as  Instruction  1,  except  that  if  a  rock  blocks 
the  path,  move  west  around  it. 

3.  Sweep>-east-returning-when-bag-full 

Move  in  a  straight  eastward  line  from  the 
current  position  to  the  eastern  boundary  of 
the  area  to  be  searched.  If  a  hiker  is  found. 
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pick  him  or  her  up;  if  doing  so  brings  the  robot 
to  its  full  capacity,  quit  this  instruction. 

4.  Sweep-west-returning-when-bag-full 

Same  as  Instruction  3,  except  move  in  a  straight 
westward  line  from  the  current  position  to  the 
western  boundary  of  the  area  to  be  searched. 

5.  Sweep-south 

Move  in  a  straight  southward  line  from  the 
current  position  to  the  southern  boundary  of 
the  area  to  be  searched.  Ignore  any  hikers. 

6.  Sweep-west 

Same  as  Instruction  5,  except  move  in  a  straight 
westward  line  from  the  current  position  to  the 
western  boundary  of  the  area  to  be  searched. 

7.  Pick-up-any-objects 

Pick  up  as  many  hikers  at  the  current  location  as 
the  capacity  of  the  robot  allows. 

8.  Return-when-bag-full 

Search  tundra,  looking  for  hikers.  When  the 
robot’s  capacity  of  hikers  has  been  picked  up,  or 
when  the  entire  tundra  has  been  searched, 
return  to  the  point  of  origin  and  turn  off. 

9.  Return-to-starting-point 

From  the  current  position,  return  to  the  point  of 
origin. 

10.  Negotiate-rock-to-east-returning-when-bag-full 

Assumes  that  there  is  a  rock  just  ahead  of  the 
robot,  to  the  east.  Moves  the  robot  such  that, 
when  the  instruction  ends,  the  robot  is  just  to 
the  east  of  the  rock,  at  the  same  latitude  as  when 
it  started.  If  any  hikers  are  found  while 
negotiating  the  rock,  they  arc  picked  up.  If 
doing  so  brings  the  robot  to  its  capacity,  the 
instruction  terminates,  whether  or  not  the  rock 
has  been  negotiated. 
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11.  Negotiate-rock-to-west-returning-whcn-bag-full 

Same  as  Instruction  10,  except  assumes  that 
there  is  a  rock  just  ahead  of  the  robot,  to  the 
west.  Moves  the  robot  such  that,  when  the 
instruction  ends,  the  robot  is  just  to  the  west  of 
the  rock,  at  the  same  latitude  as  when  it  started. 

12.  Zig-zag-southwest 

From  the  current  position,  zigzag  southwest 
until  reaching  the  southern  or  western 
boundary  of  the  area  being  searched,  whichever 
occurs  first.  Ignore  any  hikers. 

3.  URW,  has  been  approached  by  the  U.  S.  State  Department.  The  State  Department  is 
concerned  because  it  has  received  reports  that  embassies  around  the  world  have  electronic 
bugs  embedded  in  their  walls.  The  State  Department  wants  to  know  if  URW  can  supply  a  robot 
that  can  locate  these  bugs.  Fortunately,  URW’s  engineers  have  just  finished  developitig  a  new 
sensor,  and  they  think  it  can  be  used  for  finding  bugs.  URW  therefore  decides  to  modify  its 
robot  domain  so  it  can  produce  this  new  type  of  robot  in  addition  to  those  in  its  old  product 
line. 

a.  For  each  of  the  following  decisions  in  the  decision-making  process,  state  a 
requirement  for  the  robot: 

(1)  Terrain 

(2)  Object  type 

(3)  Choose  if  objects  are  to  be  carried 

(4)  Ending  position 

(5)  Carrying  capacity 

b.  Identify  the  decisions  from  (1)  through  (5)  whose  range  of  allowed  values  must  be 
changed  to  accommodate  the  new  robot. 

(Optional) 

c.  Draw  the  software  architecture  for  the  robot,  using  the  domain  architecture  as  a 
starting  point. 

d.  Name  some  instructions  from  Question  2  that  you  think  could  be  used  without 
modification. 

e.  Name  some  instructions  from  Question  2  that  could  be  used  with  modification.  What 
do  you  think  the  modifications  might  be? 

f.  Asa  domain  engineer  for  URW,  what  new  components,  if  any,  do  you  think  would  be 
necessary? 
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UNIT  4:  DOMAIN  ENGINEERING 


TEACHER  NOTES  FOR  IN-CLASS  DISCUSSION 


1 .  Compare  results  of  the  laboratory  activity.  Is  there  more  than  one  robot  software  architecture 
that  satisfies  the  needs  of  each  client?  \^y  or  why  not? 

2.  What  other  kinds  of  robots  could  be  produced  by  the  URW  domain?  This  is  really  an 
open-ended  question  and  should  produce  an  interesting  discussion. 


TEACHER  NOTES  FOR  HOMEWORK 

1.  Considering  the  domain  of  the  URW,  would  you,  as  Chairman  of  the  Board,  want  to  produce 
robots  to; 

a.  Plant  corn 

b.  Pick  water  lilies 

c.  Feed  incubator  babies 

In  making  your  decision,  are  there  enough  similarities  to  warrant  asking  your  domain 
engineers  to  write  additional  instruaions? 

Note  to  teachers:  Familiarity  with  Karel  the  Robot  is  helpful  on  the  following  questions. 

2.  The  instructions  in  the  left  column  were  used  to  implement  the  software  for  a  robot  that 
searches  a  tundra  for  lost  hikers.  Each  instruction  in  the  left  column  is  an  adaptation  of  an 
architectural  part  in  the  right  column.  Match  each  instruction  in  the  left  column  with  the 
architectural  part  in  the  right  column. 


Instructions 


Architectural  Parts 


1 .  Advance-north-moving-east-to-avoid-rocks- 
returning-when-bag-full 

Move  north  one  unit.  If  a  rock  blocks  the 
path,  move  east  around  it.  If  a  hiker  is 
found,  pick  him  or  her  up;  if  doing  so  brings 
the  robot  to  its  full  capacity,  quit  this  instruction. 


A.  Perform  Mission 

B.  Navigate  Terrain 

C.  Negotiate  Obstacle 

D.  Handle  Object 

E.  Tferminate  Mission 


2.  Advance-north-moving-west-to-avoid-rocks- 
returning-when-bag-full 


Same  as  Instruction  1,  except  that  if  a  rock 
blocks  the  path,  move  west  around  it. 
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3.  Sweep-east-returning-when-bag-full 

Move  in  a  straight  eastward  line  from  the 
current  position  to  the  eastern  boundary  of  the 
area  to  be  searched.  If  a  hiker  is  found,  pick  him 
or  her  up;  if  doing  so  brings  the  robot  to  its  full 
capacity,  quit  this  instruction. 

4.  Sweef>-west-returning-when-bag-full 

Same  as  Instruction  3,  except  move  in  a  straight 
westward  line  from  the  current  position  to  the 
western  boundary  of  the  area  to  be  searched. 

5.  Sweep-south 

Move  in  a  straight  southward  line  from  the 
current  position  to  the  southern  boundary  of 
the  area  to  be  searched.  Ignore  any  hikers. 

6.  Sweep-west 

Same  as  Instruction  5,  except  move  in  a  straight 
westward  line  from  the  current  position  to  the 
western  boundary  of  the  area  to  be  searched. 

7.  Pick-up-any-objects 

Pick  up  as  many  hikers  at  the  current  location  as 
the  capacity  of  the  robot  allows. 

8.  Return-when-bag-full 

Search  tundra,  looking  for  bikers.  When  the 
robot’s  capacity  of  hikers  has  been  picked  up,  or 
when  the  entire  tundra  has  been  searched, 
return  to  the  point  of  origin  and  turn  off. 

9.  Return-to-starting-point 

From  the  current  position,  return  to  the  point  of 
origin. 

10.  Negotiate-rock-to-east-returning-when-bag-full 

Assumes  that  there  is  a  rock  just  ahead  of  the 
robot,  to  the  east.  Moves  the  robot  such  that, 
when  the  instruction  ends,  the  robot  is  just  to 
the  east  of  the  rock,  at  the  same  latitude  as  when 
it  started.  If  any  hikers  are  found  while 
negotiating  the  rock,  they  are  picked  up.  If 
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doing  so  brings  the  robot  to  its  capacity,  the 
instruction  terminates,  whether  or  not  the  rock 
has  been  negotiated. 

11.  Negotiate-rock-to-west-returning-when-bag-full 

Same  as  Instruction  10,  except  assumes  that 
there  is  a  rock  just  ahead  of  the  robot,  to  the 
west.  Moves  the  robot  such  that,  when  the 
instruction  ends,  the  robot  is  just  to  the  west  of 
the  rock,  at  the  same  latitude  as  when  it  started. 

12.  Zig-zag-southwest 

From  the  current  position,  zigzag  southwest 
until  reaching  the  southern  or  western 
boundary  of  the  area  being  searched,  whichever 
occurs  first.  Ignore  any  hikers. 


Answers:  1-B,  2-B,  3-B,  4-B,  S-B,  6-B,  7-D,  8-A,  9-E,  10-C,  11-C,  12-B 


3.  URW  has  been  approached  by  the  U.  S.  State  Department.  The  State  Department  is 
concerned  because  it  has  received  reports  that  embassies  around  the  world  have  electronic 
bugs  embedded  in  their  walls.  The  State  Department  wants  to  know  if  URW  can  supply  a  robot 
that  can  locate  these  bugs.  Fbrtunately,  URW’s  engineers  have  just  fimshed  developing  a  new 
sensor,  and  they  think  it  can  be  used  for  finding  bugs.  URW  therefore  decides  to  modify  its 
robot  domain  so  it  can  produce  this  new  type  of  robot  in  addition  to  those  in  its  old  product 
line. 


a.  For  each  of  the  following  decisions  in  the  decision-making  process,  state  a 
requirement  for  the  robot: 

(1)  Terrain 

Answer:  The  robot  is  to  search  buildings. 

(2)  Object  type 

Answer:  The  robot  is  to  search  for  electronic  bugs. 

(3)  Choose  if  objects  are  to  be  carried 

Artswer:  The  robot  is  to  locale  objects,  but  not  carry  them. 

(4)  Ending  position 

VaUd  answers:  The  robot  is  to  stop  when  it  locates  a  bug;  the  robot  is  to  serial  the  location 
of  each  bug  it  finds,  and  continue  until  it  has  covered  all  of  the  building;  or  both.  That  is, 
URW  should  consider  supplying  both  types  of  robots. 


(5)  Canying  capacity 

Answer:  The  robot  will  not  cany  any  otjecB. 

b.  Identify  the  decisions  from  (1)  through  (S)  whose  range  of  allowed  values  must  be 
changed  to  accommodate  the  new  robot. 

Answer:  (1)  -  new  terrain  (buildings) 

(2)  -  new  object  /)p<  (bugs) 


(Optional) 

c.  Draw  the  software  architecture  for  the  robot,  using  the  domain  architecture  a 
starting  point. 

Answer:  Draw  the  architecture  with  particular  nuances  based  on  how  the  robot  terminate 
its  mission. 

d.  Name  some  instructions  from  Question  2  that  you  think  could  be  used  without 
modification. 

e.  Name  some  instructions  from  Question  2  that  could  be  used  with  modification.  What 
do  you  think  the  modifications  might  be? 

f.  Asa  domain  engineer  for  URW,  what  new  components,  if  any,  do  you  think  would  be 
necessary? 

Answer:  The  old  search  strategies  do  not  work;  however,  realizing  that  is  not  simple 
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Test  for  Overview  of  Megaprogramming  Course 

1 .  In  the  following  table,  check  whether  the  task  would  be  done  by  an  application  engineer  or  a 

domain  engineer. 


'Bisk 

Application 

Engineer 

Domain 

Engineer 

Create  the  reusable  components  for  a  domain. 

Work  with  the  customer  to  understand  the  problem. 

Validate  the  requirements. 

Generate  the  solution. 

Define  what  is  in  the  domain. 

Define  the  process  and  support  needed  to  generate  a 
solution  for  a  customer. 

Precisely  state  the  problem. 

2.  Read  the  following  desaiption  of  the  Car4U  Company: 

Have  you  ever  wanted  a  car  that  was  tatter?  wider?  bigger?  Have  you  ever  shopped  the  car 
market  and  found  nothing  you  wanted  (and  they  stiti  wanted  a  lot  of  money  for  it)?  Well,  no 
more,  because  now  there’s  a  new  company  for  the  discriminating  buyer: 

Do  We  Have  a  Car  4  U! 

The  Car4U  Company  makes  cars  that  are  tailored  to  your  every  need  and  desire.  You  can 
have  car  seats  that  are  tailored  to  your  weight,  height,  and  width.  You  can  have  bigger 
windows  or  smaller  windows.  You  can  have  bigger  trunks  or  smaller  trunks,  if  you  want 
four-wheel  drive,  you’ve  got  R.  If  you  want  your  car  to  be  a  shade  of  blue  that  matches  your 
eyes,  we  can  do  that  too  (in  fact,  we  have  over  1 000  colors  to  choose  from!).  We  have  engines 
meant  for  cruising  at  high  speeds  and  engines  meant  for  climbing  mountains.  All  in  all, 
Car4U  has  over  3  dozen  options.  Each  one  is  meant  to  help  make  your  car  truly  your  own. 

We  work  wKh  every  customer  to  determine  exactly  what  they  want  and  then  develop  a  car 
that  suRs  their  needs.  No  longer  will  you  have  to  waR  for  the  perfect  car.  Stop  by  your  nearest 
Car4U  store  today  and  see  what  we  can  do  for  you! 


Based  on  this  description,  answer  the  following  questions.  Attach  separate  sheets  if  needed. 

a.  What  is  the  output  of  the  Car4U  Company’s  domain  engineering  activities? 


b.  What  is  the  output  of  their  application  engineering  activities? 
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3.  Read  the  following  description  of  TJ's  cash  registers  domain. 


Description  of  TJ’s  Cash  Registers  Domain 

TJ’s  Cash  Registers  domain  contains  cash  registers  that  can  be  used  in  just  about  any  retaii 
situation. 

There  are  severai  options  through  which  money  can  be  entered  into  a  cash  register.  The 
traditionai  way  is  to  accept  cash  from  the  customer  and  store  ft  in  a  removabie  money 
drawer.  In  addftion  to  the  money  drawer,  some  cash  registers  are  equipped  with  check 
imprinting  services  and/or  the  ability  to  scan  in  credH  cards,  in  all  cases,  each  cash  register 
keeps  track  of  the  amount  of  money  that  has  been  received  from  the  customer. 

Several  retail  situations  require  the  use  of  programmable  keys  that  can  store  prices  for  items 
that  are  sold  frequently.  Other  price  input  mechanisms  include  a  price  scanning  function,  a 
scale  for  items  sold  by  weight,  or  the  use  of  the  numeric  key  pad.  Only  the  numeric  key  pad 
and  the  programmable  keys  are  standard,  though  the  number  of  programmable  keys  can 
vary  from  register  to  register. 

To  show  prices  and  to  show  other  information  for  the  cashier  and  the  customer,  each  cash 
register  has  a  digital  display.  Optionally,  there  may  be  a  separate  price  display  for  the 
customer,  either  on  the  back  of  the  register  or  on  a  completely  separate,  smaller  display  that 
is  above  the  register  and  pointed  towards  the  customer.  After  every  transaction,  each 
register  automatically  outputs  a  cash  register  receipt  that  is  printed  with  the  date  and  time. 

Higher-end  cash  registers  can  be  hooked  up  to  the  store’s  Inventory  system  to  either  keep 
track  of  what  the  store  has  in  stock  (along  with  a  warning  message  when  the  stock  gets  low) 
or  to  order  items  and  have  the  customer  pick  them  up  at  a  separate  location. 


Based  on  this  domain  description,  answer  the  following  questions.  Attach  separate  sheets  if  needed, 

a.  What  are  the  members  of  the  domain? 


b.  List  the  similarities  between  the  members  of  the  domain.  Be  specific. 


c.  List  the  differences  between  the  members  of  the  domain.  Be  specific. 
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Survey  for  Overview  of  Megaprofframming  Course 

Please  answer  the  following  questions.  The  company  that  developed  the  course  material  will  use  this 
information  to  improve  the  course. 

1.  Do  you  feel  that  you  understand  the  basic  principles  of  megaprogramming  after  taking  this 

course? 


2.  Do  you  see  value  in  megaprogramming? 


3.  Would  you  like  to  learn  more? 


4.  What  activity(ies)  or  example(s)  was  most  helpful  to  you  in  understanding  megaprogramming? 


5. 


Do  you  have  any  other  suggestions  for  how  the  course  can  be  improved? 
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This  page  intentionally  left  blank. 
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Test  for  Overview  of  Megaprogramming  Course 
Teacher  Answers 


1.  In  the  following  table,  check  whether  the  task  would  be  done  by  an  application  engineer  or  a 
domain  engineer. 


Task 

Application 

Engineer 

Domain 

Engineer 

Create  the  reusable  components  for  a  domain. 

X 

Work  with  the  customer  to  understand  the  problem. 

X 

Validate  the  requirements. 

X 

Generate  the  solution. 

X 

Define  what  is  in  the  domain. 

X 

Define  the  process  and  support  needed  to  generate  a 
solution  for  a  customer. 

X 

Precisely  state  the  problem. 

X 

2.  Read  the  following  description  of  the  Car4U  Company: 

•«***«*********«*««««***«•**«»**•******«*«***•«**•*«*****«»**»»* 


Have  you  ever  wanted  a  car  that  was  taller?  wider?  bigger?  Have  you  ever  shopped  the  car 
market  and  found  nothing  you  wanted  (and  they  still  wanted  a  lot  of  money  for  it)?  Well,  no 
more,  because  now  there’s  a  new  company  for  the  discriminating  buyer: 

Do  We  Have  a  Car  4  U! 

The  Car4U  Company  makes  cars  that  are  tailored  to  your  every  need  and  desire.  You  can 
have  car  seats  that  are  tailored  to  your  weight,  height,  and  width.  You  can  have  bigger 
windows  or  smaller  windows.  You  can  have  bigger  trunks  or  smaller  trunks.  If  you  want 
four<wheel  drive,  you've  got  it.  If  you  want  your  car  to  be  a  shade  of  blue  that  matches  your 
eyes,  we  can  do  that  too  (in  fact,  we  have  over  1 000  colors  to  choose  from!).  We  have  engines 
meant  for  cruising  at  high  speeds  and  engines  meant  for  climbing  mountains.  All  in  all, 
Car4U  has  over  3  dozen  options.  Each  one  Is  meant  to  help  make  your  car  truly  your  own. 

We  work  with  every  customer  to  determine  exactly  what  they  want  and  then  develop  a  car 
that  suits  their  needs.  No  longer  will  you  have  to  wait  for  the  perfect  car.  Stop  by  your  nearest 
Car4U  store  today  and  see  what  we  can  do  for  you! 

**««4>««4i****4>«««««««*«««*4t******««««****«4>**««*«c«*«***»*«««*««t4ti» 


Based  on  this  description,  answer  the  following  questions.  Attach  separate  sheets  if  needed. 
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a.  What  is  the  output  of  the  Car4U  Company's  domain  engineering  activities? 

•  Domain  engineering  would  (1)  create  all  of  the  different  car  components  that  would  be 
needed  to  make  a  car,  (2)  create  the  ordered  list  of  questions  that  the  car  salesperson  would 
ask  the  customer,  and  (3)  create  the  instructions  for  how  the  actual  car  builders  would  put 
together  the  car  based  on  the  specific  needs  of  a  specific  customer. 

b.  What  is  the  output  of  their  application  engineering  activities? 

Application  engineering  would  (1)  talk  with  the  customer  to  understand  what  the  customer 
wanted  in  a  car,  (2)  use  that  understanding  to  come  up  with  a  precise  statement  of  what 
was  needed  in  the  car,  (3)  make  sure  that  this  precise  statement  was  what  the  customer 
wanted,  and  (4)  generate  the  car  (with  help  from  the  actual  car  builders)  that  met  the 
customer’s  specific  need. 


3.  Read  the  following  description  of  TJ's  cash  registers  domain. 


Description  of  TJ’s  Cash  Registers  Domain 

TJ  Inc.  makes  cash  registers  that  can  be  used  in  just  about  any  retail  situation. 

There  are  several  options  through  which  money  can  be  entered  into  a  cash  register.  The 
traditional  way  is  to  accept  cash  from  the  customer  and  store  it  in  a  removable  money 
drawer.  In  addition  to  the  money  drawer,  some  cash  registers  are  equipped  with  check 
imprinting  services  and/or  the  ability  to  scan  in  credit  cards,  in  ail  cases,  each  cash  register 
keeps  track  of  the  amount  of  money  that  has  been  received  from  the  customer. 

Several  retail  situations  require  the  use  of  programmable  keys  that  can  store  prices  for  items 
that  are  sold  frequently.  Other  price  Input  mechanisms  include  a  price  scanning  function,  a 
scale  for  items  sold  by  weight,  or  the  use  of  the  numeric  key  pad.  Only  the  numeric  key  pad 
and  the  programmable  keys  are  standard,  though  the  number  of  programmable  keys  can 
vary  from  register  to  register. 

To  show  prices  and  to  show  other  information  for  the  cashier  and  the  customer,  each  cash 
register  has  a  digital  display.  Optionally,  there  may  be  a  separate  price  display  for  the 
customer,  either  on  the  back  of  the  register  or  on  a  completely  separate,  smaller  display  that 
is  above  the  register  and  pointed  towards  the  customer.  After  every  transaction,  each 
register  automatically  outputs  a  cash  register  receipt  that  is  printed  with  the  date  and  time. 

Higher-end  cash  registers  can  be  hooked  up  to  the  store’s  inventory  system  to  either  keep 
track  of  what  the  store  has  in  stock  (along  with  a  warning  message  when  the  stock  gets  low) 
or  to  order  items  and  have  the  customer  pick  them  up  at  a  separate  location. 


Based  on  this  domain  description,  answer  the  following  questions.  Attach  separate  sheets  if  needed. 
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a.  What  are  the  members  of  the  domain? 

The  members  ofTJ's  Cash  Registers  domain  are  cash  registers  that  could  be  built  by  TJ  Inc. 

b.  List  the  similarities  between  the  members  of  the  domain.  Be  specific. 

(J)  Removable  money  drawer 

(2)  Ability  to  keep  track  of  the  amount  of  money  received  by  customers 

(3)  Numeric  key  pad 

(4)  Existence  of  programmable  keys 

(5)  Digital  display 

(6)  Ability  to  output  a  cash  register  receipt 

c.  List  the  differences  between  the  members  of  the  domain.  Be  specific. 

(1)  Check  imprinting  services 

(2)  Ability  to  scan  in  credit  cards 

(3)  Price  scanning  function 

(4)  Scale  for  items  sold  by  weight 

(5)  Number  of  programmable  keys 

(6)  Price  display  on  back  of  register 

(7)  Separate  price  display  pointed  towards  the  customer 

(8)  Hook-up  to  store’s  inventory  system  to  keep  track  of  what's  in  stock 

(9)  Hook-up  to  store’s  inventory  system  to  order  items  to  be  picked  up  at  separate  location 


«•««*«««««*  *«««*««»««4>**««4>«*«4i******»««*«**»«*  *»•**»•«****•»**••»•**•*  »*«••«»«*»*•• 


Survey  for  Overview  of  Megaprogramming  Course 
Teacher  AnsvKers 


There  are  no  right  or  wrong  answers  on  this  section.  A  suggestion  for  this  survey  would  be  to  hand  it 
to  the  students  after  they  have  completed  the  test  and  give  them  extra  credit  if  they  Hll  it  out  and  hand 
it  in  the  next  day. 
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PREFACE 


The  Software  Productivity  Consortium  (Consortium)  is  a  cortsortium  of  aerospace  companies  that 
employ  many  of  today  and  tomorrow’s  software  developers.  These  industries  have  a  strong  interest 
in  the  quality  of  the  software  education  today’s  youth  receive,  for  a  well-trained  engineer  is  a  valuable 
asset.  The  Consortium  has  therefore  begun  an  ambitious  program  to  infuse  modern  software  develop¬ 
ment  concepts  into  the  computing  curriculum.  This  program,  run  by  the  Megaprogramming  Curricu¬ 
lum  Project,  is  working  with  high  schools  and  universities  to  devise  new  and  innovative  curricula  and 
supporting  materials. 

The  project’s  first  product  is  the  Overview  of  Megaprogramming  Course.  As  of  this  writing,  high  schools 
in  Virginia  and  West  Virginia  have  incorporated  the  course  into  their  school  year.  Based  on  reactions 
from  ^ose  schools,  the  Consortium  believes  that  the  course  provides  an  excellent  introduction  to  me¬ 
gaprogramming  (a  foundation  for  many  important  software  concepts,  as  the  report  will  explain)  and 
is  use^l  to  teachers  who  wish  to  keep  their  computer  science  courses  in  step  with  the  state  of  the  art. 

The  Consortium’s  original  model  for  introducing  the  course  at  a  high  school  was  to  provide  personal 
instruction  and  consultation  for  teachers  who  expressed  an  interest  in  it.  This  approach  is  becoming 
impractical  as  use  of  the  course  expands.  In  any  event,  even  one-on-one  instruaion  runs  the  risk  of 
omitting  information.  Hence  this  report,  whidi  captures  the  concepts  covered  during  a  typical  tutorial 
session.  It  is  not  entirely  a  substitute  for  face-to-face  contact,  but  it  should  help  the  reader  understand 
megaprogramming.  Moreover,  it  should  convince  the  reader  of  the  need  for  teaching  the  course. 

The  theme  of  this  paper  is  that  education  in  software  development  has  for  too  long  stressed 
programming  and  computer  science  at  the  expense  of  engineering.  Industry  wants  software  engineers, 
not  computer  scientists.  Yet  software  engineering  is  still  an  optional  course  for  most  undergraduate 
computer  science  majors  and  is  seldom,  if  ever,  mentioned  in  high  schools,  lb  be  sure,  teaching 
engineering  requires  a  scientific  basis,  and  developing  software  is  ultimately  about  programming;  both 
topics  are  important.  But  to  stress  them  at  the  expense  of  software  engineering  keeps  the  student  ftom 
learning  the  full  truth  about  why  industry  considers  developing  software  to  be  so  hard. 

The  Megaprqgramming  Curriculum  Project  hopes  educators  will  agree  that  megaprogramming 
deserves  a  place  in  a  student’s  education.  Tb  the  degree  that  it  can,  the  project  actively  seeks  to  work 
with  schools  in  instituting  megaprogramming,  in  soliciting  feedback  on  the  course,  and  in  helping 
instructors  revise  and  expand  the  megajnogramming  curriculum  material. 
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1.  INTRODUCTION 

This  report  is  part  of  the  Software  Productivity  Consortium's  Overview  of  Megaprogramming  Course. 
The  course,  aimed  at  high  school  and  freshman  undergraduate  computer  science  students,  teaches 
industrial  software  development  concepts.  It  gives  students  a  realistic  look  at  how  professionals  build 
software.  It  covers  important,  practical  issues  often  absent  from  today’s  classes.  Although  the  course 
is  brief  (1  to  2  weeks),  it  helps  students  relate  their  programming  knowledge  to  the  real  world. 

The  Overview  of  Megaprogramming  Course  focuses  on  software  developed  by  the  technique  known  as 
megaprogramming.  The  megaprogramming  technique  is  very  different  from  how  most  companies 
(and  students)  develop  software  today.  Students  develop  a  single  program  in  response  to  a  homework 
assignment;  a  company  develops  a  single  program  in  response  to  a  business  opportunity.  By  contrast, 
people  using  megaprogramming  develop  a  whole  product  line — that  is,  a  set  of  programs.  In  doing 
so,  they  use  sound  engineering  principles  that  give  them  a  solid  understanding  of  each  program’s  prop¬ 
erties.  This  understanding  may  not  help  a  company  as  it  pursues  a  single  business  opportunity,  but 
companies  seldom  pursue  single  opportunities;  they  go  after  sets  of  opportunities.  Megaprogramming 
helps  companies  position  themselves  to  obtain  sets  of  opportunities.  As  this  report  will  argue,  it  can 
also  be  helpful  to  students. 

The  development  of  the  megaprogramming  technique  has  been  sponsored  by  the  Advanced  Research 
Projects  Agency  (AREA)  to  help  increase  software’s  quality  and  decrease  its  cost  (Boehm  and  Scherlis 
1992).  If  megaprogramming  is  widely  adopted,  it  will  have  a  profound  influence  on  how  people  build 
software.  The  difference  will  be  as  dramatic  as  when  people  first  switched  from  assembly  languages 
to  FORTRAN  or  Pascal. 

This  report  provides  an  introduction  to  megaprogramming.  It  is  intended  for  anyone  wanting  to  learn 
enough  about  megaprogramming  to  teach  the  Overview  of  Megaprogramming  Course.  It  is  one  part  of 
the  materials  distributed  with  the  course  and  is  best  read  in  conjunction  with  the  other  materials.  It 
does  not  assume  familiarity  with  them,  but  it  references  the  leaure  notes,  slides,  and  laboratory  mate¬ 
rial.  This  may  prove  helpful  to  an  instructor  preparing  lectures:  a  reference  to  a  slide  (e.g.,  “See 
Slide  1-4”)  generally  indicates  additional  material  that  can  be  discussed  when  presenting  that  slide. 
Also,  for  each  slide.  Appendix  A  shows  the  material  in  this  report  most  relevant  to  that  slide. 

This  report  is  not  to  be  viewed  as  a  complete  definition  of  megaprogramming.  Rather,  it  presents 
megaprogramming’s  fundamental  concepts  and  shows  why  these  concepts  are  important  in  software 
development. 

Moreover,  this  report  argues  that  megaprogramming  should  be  a  basic  part  of  a  student’s  education 
in  computing.  The  Overview  of  Megaprogramming  Course  is  a  first  step  in  this  direction.  The  course  was 
created  based  on  the  belief  that  the  computing  curriculum  has  several  significant  deficiencies.  The 
next  several  sections  (1.1  through  1.3)  address  this  point 
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1.1  OVERVIEW  OF  THE  CURRENT  COMPUTER  SCIENCE  CURRICULUM 

As  of  this  writing,  computer  science  education  isa  little  over  three  decades  old.’  Those  years  have  seen 
considerable  change  in  how  people  develop  software.  Once  it  was  largely  an  individual  or  small  team 
activity  that  generally  yielded  programs  of  imder  50,000  lines  of  code — small  in  toda/s  terms.  This 
is  no  longer  the  case.  Advances  in  hardware  have  resulted  in  huge  increases  in  available  memory 
which,  in  turn,  have  led  to  larger  programs.  Today,  large  organizations  routinely  write  programs 
containing  millions  of  lines  of  code.  They  spend  several  years  doing  so  and  set  up  a  complex  hierarchy 
to  build  and  maintain  their  products.  Individuals  and  small  teams  still  exist,  but  they  work  in  ways  that 
were  inconceivable  30  years  ago.  They  rely  on  a  complicated  software  infrastructure  of  compilers, 
operating  systems,  editors,  graphics  libraries,  and  the  like. 

Computer  science  education  has  changed  little  in  this  period.  The  standard  computer  science 
curriculum,  now  and  then,  begins  by  introducing  students  to  programming.  Students  learn  the  syntax 
and  semantics  of  a  computer  programming  language  such  as  Pascal  or  Ada  and  are  t.aught  some 
rudimentary  concepts  of  formulating  algorithms  to  solve  problems  and  verifying  these  algorithms  by 
creating  and  executing  test  cases.  They  apply  this  knowledge  to  formulate  algorithms  in  some 
high-level  programming  language,  which  they  then  compile,  execute,  and  test.  This  fills  up  one  course; 
subsequent  courses  introduce  such  topics  as  the  science  of  algorithm  analysis,  the  design  and 
impiementation  of  operating  .systems,  or — often  only  in  a  student’s  final  undergraduate  year — a 
discussion  of  software  engineering,  that  is,  how  professionals  build  software. 

This  curriculum  model,  shown  in  Figure  1,  makes  students  reasonably  adept  at  solving  simple 
problems  after  only  one  course.  This  is  commendable,  but  it  has  two  significant  disadvantages: 

•  A  introduces  students  to  software  development  before  teaching  them  tacf  science  they  might  use  to 
analyze  the  qualipt  of  their  software.  Real  software  must  do  more  than  simply  compute  the  right 
answer.  It  must  execute  efficiently.  Its  interface  must  be  ft^iendly  to  its  users.  It  must  integrate 
smoothly  with  the  system  of  which  it  is  a  part.  Other  people  must  be  able  to  understand  it.  In 
the  hard  sciences,  such  as  chemistry  or  physics,  students  immediately  learn  quantitative 
analysis  techniques  to  address  issues  analogous  to  these.  Quantitative  and  qualitative  analysis 
techniques  exist  for  software,  but  students  seldom  learn  them  in  their  first  course.  As  a  result, 
students  learn  to  see  software  development  as  an  art  or  craft,  whereas  it  should  be  an 
engineering  activity — an  application  of  scientific  principles. 
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Figure  1.  The  Current  Curricuium  Model  for  Teaching  Coisputing 

•  The  current  curriculum  model  focuses  on  programming,  a  very  small  portion  of  the  software 
devdopment  process  (see  Section  2).  The  programming  part  is  most  amenable  to  conaete 
analysis  and  requires  the  least  abstract  thought.  However,  as  Section  1.2  discusses,  most 
fundamental  skills  a  software  developer  needs  are  not  part  of  programming  per  se.  These  skills 
are  not  usually  taught  until  the  software  engineering  course.  Instead,  students  learn 
workaround  techniques  that  are  of  questionable  value  to  a  professional  (Prey,  Cohoon,  and 

1.  Purdue  Univeisity  founded  the  United  States'  first  computer  science  department  in  1962. 
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Fife  1994),  By  the  lime  they  take  a  software  engineering  course,  the  undesirable  techniques 
are  firmly  entrenched  in  their  minds. 

1.2  DEFINITION  OF  TERMS 

This  report  so  far  has  discussed  “building"  and  “developing”  software,  and  might  also  have  included 
commonly  used  words  like  “create,”  “produce,”  and  “•  /rite.”  Students  earn  degrees  in  Computer  Sci¬ 
ence.  They  take  courses  with  titles  like  Introduction  to  Programming  and  Software  Engineering.  They 
use  the  skills  they  learn  to  develop  software.  What,  exactly,  is  the  relationship  between  all  these  terms? 

Answering  this  question  requires  a  combination  of  historical,  academic,  and  industrial  perspeaives. 
Industry’s  goal  is  to  develop  software.  Hence,  the  phrase  software  development  i  .  '’ers  to  the  whole 
process  of  creating  and  rewriting  software,  starting  with  the  first  realization  of  its  need,  on  through 
its  first  use,  and  from  there  through  bug  fixes  and  enhancements  to  the  time  when  it  becomes  obsolete 
and  is  finally  discarded  (see  Slide  1-4).  People  use  this  and  words  like  build,  develop,  write,  and  create 
interchangeably — although  Brooks  (1987)  reports  an  epiphany  on  realizing  their  distinction.  “I  still 
remember  the  jolt  I  felt  in  1958  when  I  first  heard  a  friend  talk  about  building  a  program,  as  opposed 
to  writing  one,”  he  writes.  “In  a  flash  he  broadened  my  whole  view  of  the  software  process.” 

Software  development,  the  previous  paragraph  claims,  is  a  process.  What  does  this  imply?  Webster’s 
Dictionary  (Merriam  1977)  defines  a  process  as  “a  series  of  actions  conducted  to  an  end.”  An  orga¬ 
nization  can  perform  a  process  in  many  ways;  many  are  chaotic  and  poorly  understood.  These  are  the 
bane  of  an  organization,  for  poorly  understood  actions  are  hard  to  plan  and  manage.  Organizations 
want  their  processes  to  introduce  engineering.  In  engineering  (to  paraphrase  Webster’s),  science  is 
applied  to  processes  to  make  them  useful  to  humanity.  In  other  words,  software  development  that  in¬ 
corporates  engineering  has  a  scientific  basis.  'This  science  helps  organizations  predict  the  properties 
of  software  without  actually  building  it— just  as  a  civil  engineer  uses  the  science  of  structural  mechan¬ 
ics  to  predict  the  load  a  bridge  can  hold  without  actually  building  it.  Similarly,  science  also  helps  orga¬ 
nizations  create  and  perform  a  software  process,  just  as  chemistry  helps  a  chemical  engineer  create 
and  perform  a  process  to  manufaaure  chemicals. 

Software  engineering,  then,  is  software  development  using  engineering.  The  science  underlying  this 
engineering  comes  in  part  from  computer  science.  Computer  science  lets  software  engineers  predict 
many  important  properties  of  software.  For  example,  algorithm  analysis  lets  them  know  that  sorting 
n  elements  takes  time  proportional  to  n  Inn .  Computer  science  also  provides  standard  algorithms  and 
techniques.  Backus  (1978)  reports  that  writing  the  first  high-level  language  compiler  took  3  years. 
Ibday,  thanks  to  research  in  areas  like  formal  languages  and  parsing,  students  taking  a  compiler  class 
learn  a  well-defined  science  that  lets  them  complete  a  compiler  in  a  single  semester. 

Computer  science  is  not  the  only  science  needed  in  software  engineering.  Large  teams — sometimes 
thousands  of  people — develop  software.  Managing  these  teams  is  a  complex  social  process,  and  so  the 
social  sciences,  notably  psychology,  have  made  important  contributions  to  software  engineering; 
Weinberg  (1971)  is  an  excellent  example.  Business  sciences,  too,  have  contributed  their  share,  tailor¬ 
ing  management  theories  to  software  (Humphrey  1989)  and  providing  models  for  estimating  the  costs 
of  developing  software  (Boehm  1981). 

This  broad  focus  distinguishes  software  engineering  from  programming.  Programming  is  usually 
taken  to  mean  the  parts  of  software  development  concerned  only  with  writing  and  testing  programs. 
Programming  courses  do  not,  as  a  rule,  teach  science.  Nor  do  they  teach  a  process  of  software 
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development,  engineering-based  or  otherwise.  Students  who  only  learn  programming  may  know  how 
to  create  programs,  but  they  do  not  know  how  to  assess  them.  They  also  do  not  appreciate  the 
multidisciplinary  nature  of  developing  software. 

In  a  famous  debate  at  the  annual  Computer  Science  Conference  (CACM  1989),  Edsger  Dijkstra 
argued  that  software  engineering  is  not  realty  engineering  at  all.  He  claimed  computer  science  is  still 
too  young  to  provide  enough  science  for  software  development  to  be  an  engineering  discipline  like 
civil  or  electrical  engineering.  Even  his  opponents  accepted  his  opinion,  at  least  in  part.  They  realize 
that  “software  development”  more  accurately  describes  what  goes  on  in  industry  today  than  does 
“software  engineering.”  This,  however,  does  not  imply  people  should  avoid  teaching  what  software 
science  and  engineering  is  known.  Moreover,  software  is  developed  in  response  to  a  problem  in  some 
area  such  as  civil  or  electrical  engineering.  The  science  from  these  areas  can  and  should  be  put  to  use 
during  software  development.  Computer  science  courses  stress  this  point  all  too  infrequently. 

IJ  PROBLEMS  WITH  THE  CURRENT  CURRICULUM 

The  discussion  in  the  previous  sections  leads  to  the  following  description  of  specific  problems  with  the 
current  curriculum: 

•  The  initial  emphasis  is  on  programmii^,  widely  regarded  as  the  easiest  part  of  software 
development  (Ince  1988).  Certainly,  mastering  programming  requires  grasping  many  new 
language  and  logic  concepts,  and  is  not  a  trivial  activity.  But  neither  are  any  of  the  other  aspects 
of  software  development,  and  students  deserve  to  learn  about  them  as  well. 

•  Science  and  ei^neering  skills  are  played  down.  Students  spend  so  much  time  learning 
programming,  they  forget  that  programs  are  written  to  achieve  an  end.  Professional  software 
developers,  when  they  build  a  program,  must  be  facile  in  areas  other  than  programming.  If 
they  are  writing  satellite  control  software,  they  must  understand  equations  of  satellite  motion. 
If  they  are  writing  an  accounting  package,  they  must  understand  business  science.  The 
computing  curriculum,  by  contrast,  emphasizes  programming  and  computer  science  concepts 
without  asking  students  to  apply  other  sciences. 

•  Students  are  discouraged fivm  usit^  existing  software.  Professionals  strive  to  avoid  wri  ting  code 
if  they  or  someone  else  have  written  it  before.  They  try  to  reuse  existing  code.  Doing  so  is  not 
always  easy,  but  the  savings  in  time  and  effort  is  often  immense.  Students  do  not  learn  reuse 
techniques  such  as  megaprogramming  and  are  often  informed  that  using  somebody  else’s  code 
is  plagiarism.  Plagiarism  aside,  the  result  is  that  students  must  reenter  code  they  have  written 
before — a  time-wasting,  rote  acthity.  From  a  pedagogic  perspective,  students  learn  computer 
science  but  not  software  engineering.  They  see  computer  science  concepts  building  on  pre¬ 
viously  learned  computer  science  concepts  (for  example,  analysis  of  sorting  routine  execution 
time  builds  on  the  science  of  algorithm  analysis),  but  they  do  not  see  engineering  concepts 
building  on  other  en^neering  concepts. 

1.4  THE  MEGAPROGRAMMING  CURRICULUM  PROJECT 

Addressing  the  problems  with  the  current  curriculum  is  the  objective  of  the  Megaprogramming 
Cuniculum  Project.  This  project,  founded  in  1992  by  the  Software  Producdvity  Consortium  (the 
Consortium),  has  the  long-range  goal  to  create,  foster,  and  encourage  curricula  for  high  schools  and 
universities  that  include  more  software  engineering. 
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The  project  is  accomplishing  its  long-term  goals,  in  part,  by  creating  short  courses.  Instructors  use 
these  courses  as  special  topics  units  that  introduce  students  to  software  engineering  concepts. 
Tfeachers  also  gain  knowledge  of  software  engineering.  They  incorporate  this  knowledge  into  their 
regular  courses.  The  Megaprogramming  Curriculum  Project’s  Overview  of  Megaprogramming  Course 
is  a  broad  overview  of  modern  software  engineering. 

1.5  PURPOSE  OF  THIS  REPORT 

This  report  serves  the  following  purposes; 

*  The  report  compUmaUs  the  lecture  notes  for  the  Overview  of  Megaprogrammiog  Course.  The 
notes  are  organized  as  slides  suitable  for  making  into  transparencies;  each  slide  has  an  accom¬ 
panying  page  of  explanatory  notes.  This  organization,  suited  to  a  lecture,  necessarily  abridges 
the  notes.  This  report  provides  information  that  could  not  fit  into  the  notes.  Sometimes  this 
information  provides  context;  while  not  likely  to  be  incorporated  into  a  lecture,  it  shows  the 
importance  of  megaprogramming  in  industry  and  academia.  Other  times,  the  information 
simply  did  not  fit  into  the  flow  of  the  lecture. 

*  The  report  provides  instructors  with  answers  to  questions  perceptive  students  might  ask.  This 
information  has  often  been  omitted  from  the  slides  because  it  cannot  fit  into  the  format. 
Indeed,  presenting  all  of  it  would  result  in  a  course  much  longer  than  the  anticipated  1  to  2 
weeks.  However,  instruaors  will  want  to  be  prepared  to  go  into  depth  on  certain  topics  when 
students  show  interest. 

*  Thereportincreasesawarenessofindustrudpracticesinthealueationaleommuniiy.  Instructors  can 
use  this  knowledge  to  teach  practical  aspects  of  software  development,  introduce  realistic 
concerns,  and  create  projects  and  assignments  incorporating  more  real-world  considerations. 

*  The  report  assists  instructors  in  preparit^  their  own  megaprogramming  lectures,  examples,  and 
exercises.  The  Overview  of  Megaprogramming  Course  cannot  possibly  suit  everyone’s  style.  The 
Megaprogramming  Curriculum  Project  encourages  instructors  to  develop  their  own 
materials.  This  has  been  its  model  since  the  very  first  year,  since  curriculum  propagation  on 
a  nationwide  scale  is  beyond  the  scope  of  a  single  project. 

1.6  AUDIENCE  FOR  THIS  REPORT 

This  report  is  intended  primarily  for  high  school  and  university  instructors  who  are  interested  in 
teaching  the  Overview  of  Megaprogramming  Course.  It  is  also  of  interest  to  anyone  who  wants  to  know 
about  the  Megaprogramming  Curriculum  Project  and  its  tenets.  The  reader  should  understand 
enough  programming  and  basic  computer  sdence  concepts  to  teach  an  introductory  course. 

1.7  ORGANIZA’nON  OF  THIS  PAPER 

The  material  in  this  report  is  organized  as  follows: 

*  Section  1  contains  an  overview  of  the  current  computer  science  curriculum,  definitions  of  basic 
terms,  problems  in  the  curriculum,  and  a  description  of  the  Megapre^amming  Curriculum 
Project  and  how  it  addresses  those  problems. 
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•  Section  2  discusses  a  hypothetical  software  project,  intending  to  present  a  reasonable  picture 
of  the  current  state  of  industrial  software  development. 

•  Section  3  discusses  the  government’s  concern  about  the  growing  costs  of  software 
development,  and  the  Megaprogramming  Effort,  which  is  responsible  for  starting  the 
Megaprogramming  Curriculum  Project. 

•  Section  4  covers  megaprogramming  in  detail;  t^at  it  is  and  why  practicing  it  seems  likely  to 
improve  the  state  of  software  development. 

•  Section  5  discusses  the  importance  of  megaprogramming  in  academia,  arguing  for  adoption 
of  the  ideas  of  the  Megaprogramming  Curriculum  Project  into  high  school  and  college 
curricula. 

•  Appendix  A  delineates  how  the  lecture  material  relates  to  the  organization  of  this  report. 

•  Appendix  B  discusses  the  structure  of  the  Overview  of  Megaprogramming  Course. 

1.8  TYPOGRAPHIC  CONVENTIONS 

This  report  uses  the  following  typographic  conventions; 


Serif  font .  General  presentation  of  information. 

ItaUcaed  serif  font  .  Mathematical  expressions  and  publication  titles. 

Boldfaced  serif  font . Section  headings  and  emphasis. 

Boldfaced  italicized  serif  font .  Run-in  headings  in  bulleted  lists. 


2.  SOFTWARE  DEVELOPMENT  IN  INDUSTRY 

TODAY 

Discussing  the  importance  of  megaprogramming  or  the  need  for  curriculum  changes  requires  an 
understanding  of  today’s  software  development  practices.  This  section  describes  issues  that 
companies  in  the  software  business  face.  It  goes  well  beyond  software,  for  software  is  a  means  to  an 
end  and  is  influenced  and  constrained  by  a  variety  of  forces  that  at  first  seem  only  peripherally  related. 
Yet  these  forces  shape  the  software  throughout  its  useful  lifetime.  Therefore,  understanding  them  is 
important. 

The  lectures  and  laboratory  in  the  Overview  of  Megaprogramming  Course  refer  to  United  Robot 
Workers,  Inc.  (URW),  a  fictitious  company  in  the  robot  business.  How  does  URW  conceive  the  need 
for  a  particular  robot  model?  How  does  it  turn  that  need  into  a  working  product? 

2.1  EXAMPLES  OF  SOFTWARE  PROJECTS 

The  answer  to  these  questions  is  that  URW  follows  a  software  development  process.  In  software 
engineering,  a  process  is  best  thought  of  as  a  set  of  activities  carried  out  in  some  predefined  order.  An 
algorithm  is  one  example  of  a  process.  An  algorithm  is  a  very  precisely  defined  process,  sufficiently 
precise  that  a  computer  can  perform  it.  Tlie  processes  that  companies  use  to  build  products  are,  as 
a  rule,  vague  in  describing  how  to  perform  eadi  activity,  when  each  activity  can  begin,  and  when  it  can 
end.  But  the  process  adds  enough  order  for  URW  to  pose  and  solve  problems  in  a  logical  sequence. 

Figure  2,  drawn  from  Slide  1-5,  shows  a  software  development  process  URW  might  follow  to  build  a 
robot.  Each  boxreprcsents  an  activity.  Arrows  between  the  boxes  show  the  order  in  which  the  activities 
must  be  performed;  an  activity  at  the  head  of  an  arrow  begins  after  the  activity  at  the  arrow’s  tail  ends. 
The  labels  on  the  arrows  are  the  products  that  result  from  each  activity. 

This  process  begins  with  the  Requirements  activity.  Here,  URW's  engineers  determine  the  problem 
they  are  trying  to  solve;  Who  is  their  customer,  and  what  is  he  or  she  trying  to  accomplish?  In  other 
words,  what  characteristics  must  a  solution  to  the  problem  possess?  Answers  to  these  questions  let 
URW  know  what  type  of  robot  to  build.  For  example,  the  laboratory  at  the  end  of  Unit  3  (see  Appen¬ 
dix  B)  asks  students  to  consider  several  different  customers.  One  is  a  farmer  who  wants  to  harvest 
corn.  Another  is  a  representative  from  the  National  Park  Service,  who  wants  to  pick  up  litter .  The  char¬ 
acteristics  of  a  solution  for  the  farmer  are  quite  different  from  those  for  the  National  Park  Service; 

•  The  general  shape  of  the  robots  will  differ,  because  of  the  terrains.  A  robot  in  a  cornfield  does 
not  have  to  contend  with  closely  padted  trees.  Furthermore,  it  must  carry  large  amounts  of 
com — hundreds  or  even  thousands  of  ears.  By  contrast,  a  robot  that  picks  up  litter  in  a  forest 
will  zigzag  around  trees,  limiting  its  size;  this  small  size  means  a  small  carrying  container,  so 
it  can  carry  a  much  smaller  volume  of  material  than  the  cornfield  robot.  These  factors  have 
implications  on  the  motor  and  power  technologies  too. 
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•  The  robots  will  need  different  software.  The  litter -carrying  robot  encounters  trees,  and  so 
needs  obstacle-avoidance  routines.  The  cornfield  robot  does  not. 


revised  product 


Figure  2.  Software  Development  Process 


The  type  of  customer  introduces  some  interesting  differences.  The  National  Park  Service  is  part  of 
the  United  States  Government,  and  the  government  does  not  buy  things  the  same  way  as  a  farmer. 
The  farmer  purchases  the  robot  at  a  store.  The  store’s  sales  staff  show  her  a  complete  product  line 
of  robots,  and  try  to  convince  her  that  one  of  their  robots  will  meet  her  needs.  If  she  agrees,  she  buys 
the  robot.  If  not,  she  either  goes  to  a  competing  store  or  decides  to  do  without  a  robot.  If  she  ends  up 
purchasing  a  robot,  she  probably  gets  one  that  does  almost  everything  she  needs  (but  not  quite)  and 
has  a  few  features  she  doesn’t  want  (rather  like  a  nonsmoker  who  buys  a  car:  ail  cars  come  with 
ashtrays). 


To  satisfy  this  market  of  farmers,  URW  engages  in  commercial  software  development.  URW  will  build 
a  line  of  robots  with  the  features  they  think  farmers  want;  they  won’t  anticipate  everyone’s  needs  per¬ 
fectly,  but  they  will  produce  a  product  that  satisfies  most  farmers  most  of  the  time.  URW  anticipates 
that  this  strategy  will  yield  hi^  sales  volume,  justifying  the  extra  costs  of  adding  sometimes  unused 
features  to  the  robot  and  its  software. 


The  government  does  not  operate  this  way.  Rather  than  selecting  from  among  a  set  of  reatfy  made 
commercially  available  "off  the  shelf’  robots,  it  will  present  its  problem  to  a  company  and  ask  them 
to  create  a  robot  that  solves  its  particular  problem.  URW  will  sign  a  contract  promising  to  build  a  robot 
that  solves  exactly  the  government’s  problem — ^no  more  and  no  1  ess.  URW  will  agree  to  build  the  robot 
at  a  predetermined  price  and  to  deliver  it  within  a  stated  time  period.  This  is  called  contractnal 
software  development. 

Software  developed  for  the  commercial  market  is  very  different  from  software  developed  under 
contract  Commercial  software  must  appeal  to  a  broad  range  of  people;  contraaual  software  must 
appeal  only  to  its  purchaser.  Commercial  software  is  develop^  in  anticipation  of  customers; 
contractual  software  is  developed  for  a  specific  customer.  Commercial  software,  then,  tends  to  be 
broader  in  scope,  with  many  features;  contractual  software,  by  comparison,  is  more  focused. 
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Unexpectedly,  commercial  software  usually  contains  fewer  lines  of  code  than  contractual  software. 
Although  more  focused,  contractual  software  tends  to  solve  problems  that  are  inherently  more 
complex  than  those  tackled  by  commercial  products.  For  example,  word  processing  (commercial)  is 
sim|%  not  as  challenging  as  satellite  control  (contractual).  The  equations  for  arranging  text  are  trivial 
compared  to  those  for  keeping  a  satellite  in  orbit  and  in  touch  with  earth. 

Fkirthermore,  commercial  and  contractual  software  buyers  have  different  expectations  of  their 
products  If  the  farmer’s  robot  fails  because  of  a  software  error,  she  will  be  justifiably  upset,  but  she 
is  not  likely  to  suffer  catastrophic  loss.  By  contrast,  failure  of  satellite  software  may  render  an  already 
launched  billion  dollar  satellite  inoperable;  failure  of  navigational  software  might  result  in  hundreds 
of  people  losing  their  lives  in  an  airplane  crash.  This  explains  why  some  conunerdal  software 
corporations  have  a  repuution  of  letting  their  users  find  errors  in  their  products,  whereas  the 
government  insists  on  extremely  rigorous  testing  of  its  software  (which  still  doesn’t  always  find  all  of 
the  errors).  It  also  explains  why  one  government  study  estimate  that  the  cost  of  testing  a  satellite 
control  program  came  to  $1,000  per  line  of  code.  Lastly,  it  explains  why  some  of  the  space  shuttle's 
hardware  and  software  dates  from  the  Apollo  program.  The  software  may  have  been  written  long 
before  anyone  knew  about  structured  programming,  and  the  hardware  may  be  antiquated,  but  both 
are  known  to  work  in  situations  where  death  is  the  price  of  failure.  NASA’s  budget  cannot  stand  the 
expense  of  rewriting  and  retesting  the  software  for  modern  hardware. 

The  software  is  not  the  only  thing  that  differs  between  contractual  and  commercial  software 
development.  The  software  development  process  itself  differs  considerably.  Figure  2  is  a  reasonable 
abstraction  of  both  cases,  but  the  details  of  each  activity  bear  closer  scrutiny  depending  on  the  model 
in  use.  The  following  discussion  (Sections  2.1.1  and  2.1.2)  will  concentrate  first  on  the  contractual 
model.  It  will  then  show  how  the  process  differs  when  URW  uses  the  commercial  model. 

2.1.1  A  Ck)miucnJAL  Software  Developmeft  Scenario 

Figure  2  shows  that  each  activity  of  a  process  yields  some  product.  The  product  that  results  from  the 
Requirements  activity  is  a  requiremeBts  specification.  This  is  a  statement  of  the  problem  URW  is  to 
solve.  The  requirements  specification  comes  from  the  customer,  at  least  initially,  because  the  custom¬ 
er  is  the  one  who  recognizes  the  problem.  In  the  contractual  software  development  model,  the  custom¬ 
er  will  create  a  preliminary  version  and  announce  that  he  wants  to  award  a  contract.  Companies  such 
as  URW  will  submit  proposals  on  developing  the  software,  giving  a  cost  and  schedule.  The  customer 
will  select  one  (typically,  the  lowest  bidder)  as  the  contractor.  The  customer  and  the  contractor  will 
work  together  to  refine  the  customer’s  preliminary  version  of  the  problem  into  a  precise  requirements 
specification.  This  specification  serves  as  a  contract  between  the  customer  and  the  contractor.  It  states 
exactly  what  software  the  contractor  must  develop  to  satisfy  the  customer. 

What  sort  of  information  does  a  requirements  specification  contain?  Figure  3  shows  a  sample  table 
of  contents,  annotated  to  explain  eadi  section.  The  guiding  rule  is  to  define  what  the  software  must 
do,  but  to  avoid  stating  how  the  software  must  do  it.  Slide  1-5  compares  requirements  specifications 
to  homework  assignments.  This  is  a  good  analogy;  the  teacher  presents  students  with  a  problem 
without  divulging  how  to  solve  it. 

Assume  that  URW  submits  the  winning  proposal.  The  requirements  spedfication  guides  URW  during 
the  next  activity;  Design.  During  this  activity,  URW  conceives  and  plans  how  the  robot  will  work.  This 
includes  such  issues  as; 
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•  What  is  the  shape  of  the  robot?  During  the  requirements  phase,  URW  will  have  noted  the 
terrain  in  which  the  robot  must  operate,  and  that  the  terrain  imposes  constraints.  During 
design,  URW  must  choose  a  shape  that  works  for  the  constraints. 

•  What  hardware  will  be  used  to  build  the  robot?  For  instance,  what  types  of  sensors  will  it  have? 
What  type  of  locomotion  medianisra  will  it  use?  Furthermore,  what  tasks  will  the  software 
perform?  That  is,  what  is  done  by  hardware  and  what  is  done  by  software? 

■  What  is  the  software  architecture?  Software  has  an  architecture,  just  like  a  house.  URW’s 
engineers  create  a  view  of  the  rc^t  control  software  as  a  set  of  interacting  componeuts.  Each 
component  will  play  a  specific  role.  For  more  information  on  the  architecture  of  the  robot 
software,  see  the  Unit  4  lecture. 


1.  lntro4ttctloiL  An  overview  of  the  (voblem:  What  is  iU 
and — broadly  speaking— what  is  the  nature  the  sdutioo 
that  will  be  proposed? 

2.  Inputs  and  Outputs.  A  description  of  how  the  system  is 
connected  to  the  outside  world.  For  example,  a  word 
processor  uses  a  keyboard  and  mouse  as  input  and  a  screen 
and  a  printer  as  output  An  automated  teller  madiine  uses 
a  keypad  and  card  reader  as  input  and  a  screen  and  a  money 
diqsenser  as  output  URWs  robots  use  sensors  and 

for  input  and  oontrd  arms  and  loocMaotion 
devices  as  outputs. 

3.  Modes  of  OpcraUoB.  A  descriptioQ  ol  the  different 
operating  modes,  as  a  user  might  coaxivc  them.  Rr 
cxam{de,  word  processors  often  have  text  entering  modes, 
ruler  setting  modes,  equation  modes,  and  table  modes. 
Modes  presiding  a  means  to  categorize  the  software 
fuDctioDS,  siniplil^g  their  description. 


4.  Description  of  Sirftirare  FtmetSons.  This  is  the  meat  of 
the  requirements  spedficatsm.  It  describes  the  legal  inputs 
to  the  ^rstem  and  how  the  system  must  reqxmd  to  each.  Thb 
response  is  stated  in  terms  of  the  outputs  produced.  It 
avoids  mentioning  algorithms  (it  is  analogous  to  bow  a 
teacher  tries  to  phrase  homework  assignments). 

5.  Reactions  to  Undesirable  Events.  The  description  of 
software  functions  describes  responses  to  legal  inputs.  This 
describes  responses  to  illegal  inputs  and  other  **\mdesirable 
events**  (like  detection  of  hardware  problems).  In  a  word 
processor,  shutting  dcfwn  is  usually  acceptable.  Software 
coQtrcJling  a  satellite  hurtling  toward  the  outer  planets 
lades  this  luxury;  it  must  try  to  recover  from  an  undesired 
event 

4.  Reqnlred  Subsets.  Systems  are  often  planned  in  full  but 
built  in  stages.  This  sectioD  describes  acceptable 
iotermediate  subsets. 

7.  Giossaryi  A  description  of  terminology  used  in  the 
requirements  spedficatioo. 


F^ure3.  Sample  Software  Requirements  Spccificatkm  Table  o(  Contents 

Figure  2  shows  the  software  development  process  as  it  appears  in  Unit  1.  In  fact.  Slide  1-S  is  a 
simplification  of  the  design  process.  Usually,  design  consists  of  two  activities:  Architectural  Design 
and  Detailed  Design,  shown  in  Figure  4.  Hie  arcMtectural  design  describes  the  software  as  a  set  of 
components.  The  detailed  design  describes  the  inner  workings  of  eadi  component  In  other  words, 
oqiericnce  has  shown  that  software  design  is  easiest  if  one  first  splits  the  design  into  parts,  then 
concentrates  on  the  details  of  those  parts.  This  is  akin  to  an  architect  designing  a  house  by  laying  out 
the  rooms  and  their  relative  positions,  then  determining  each  room’s  details — the  positions  of  the 
electrical  outlets  and  ventilating  grates,  for  instance.  The  overall  layout  of  the  major  components 
(rooms)  takes  precedence  over  the  detaUs. 

The  Requirements  activity  was  performed  jointly  by  URW  and  its  customer.  URW’s  engineers  are 
responsible  for  creating  the  design  and  do  not  expect  the  customer  to  be  involved.  As  part  of  the 
contract,  however,  the  customer  will  usually  insist  on  a  review  after  each  activity.  Thus,  the  customer 
will  hold  a  preliminary  design  review  after  architectural  design  and  a  critical  design  review  after 
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detailed  design.  These  reviews  will  assure  the  customer  that  URW's  progress  is  satisfactory  and  give 
URW  a  chance  to  get  feedback  on  the  quality  of  their  design. 


Figure  4.  Activities  of  Software  Design 


Design  is  followed  by  the  Coding  activity.  Here,  URW’s  engineers  implement  the  design  by  expressing 
it  in  a  programming  language.  The  design  envisions  a  solution  to  the  problem  expressed  by  the  require¬ 
ments;  the  code  realizes  that  vision,  just  as  a  house  is  built  to  blueprints.  Unlike  the  design,  the  code 
can  be  compiled  and  executed.  URW  can  use  it  to  run  a  robot. 

The  Coding  activity  begins  with  the  design  and  ends  when  URW’s  engineers  have  created  a  first,  tested 
version  of  each  component.  In  large  software  development  projects,  URW  will  divide  its  engineers 
into  teams  and  make  each  team  responsible  for  implementing  a  particular  set  of  components.  This 
way,  the  teams  can  work  in  parallel. 

Once  a  team  finishes  a  component,  they  begin  the  IVst  activity.  Ibsting  occurs  in  two  parts:  unit  testing 
and  integration  testing.  During  unit  testing,  a  team  tests  a  component  they  have  coded.  They  test  the 
component  as  an  indivisible  unit,  according  to  the  information  about  that  component  in  the  detailed 
design.  After  a  team  has  tested  a  component,  they  integrate  it  with  other  components  that  have  passed 
unit  testing.  They  subject  the  resulting  subsystems  to  testing;  in  other  words,  they  assemble  the  soft¬ 
ware  component-by-component,  until  all  components  have  been  integrated.  This  process  of  integra¬ 
tion  and  testing  is  referred  to  as  the  Integration  Testing  activity.  When  they  have  integrated  all 
components  and  tested  that  resulting  product,  they  have  a  working  system. 

URW  must  next  deliver  the  software  to  its  customer.  Actually,  since  URW  builds  robots  and  not  just 
software,  it  will  integrate  the  software  with  the  robot  hardware.^  It  can  then  deliver  the  robot  to  the 
National  Park  Service.  This  involves  transporting  the  robot  to  its  destination,  performing  final  tests 
in  the  actual  environment,  and  training  necessary  personnel  to  operate  it. 

Finally,  URW  must  support  the  National  Park  Service  in  using  the  robot.  Despite  URW’s  engineers’ 
best  efforts,  the  robot  will  probably  fail  occasionally  because  of  errors  URW  made  while  designing  and 
implementing  the  software.  URW  will  be  responsible  for  fixing  these  errors  and  for  delivering  the  cor¬ 
rected  software  to  the  customer.  It  is  also  likely  that  the  Park  Service  did  not  fully  understand  the  scope 
of  the  problem  and  made  errors  in  the  requirements.  Fbr  example,  they  might  have  forgotten  that  the 
trail  they  want  the  robot  to  patrol  floods  each  spring;  therefore,  th^  did  not  ask  for  a  watertight  robot. 

2.  URW  will  have  a  hardware  development  prooem  as  well  as  a  software  deveiopnieDt  process.  The  combined  effort  to 
develop  hardware  and  software  is  called  the  system  devclopawnt  froccss,  but  that’s  outside  the  scope  of  this  paper. 
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Accordingly,  they  may  ask  URW  to  redesign  its  robot.  URW  will  be  asked  to  correa  design  errors  at 
no  charge,  since  such  errors  are  its  own  fault;  but  the  Park  Service  must  pay  URW  to  implement 
changes  in  the  requirements,  because  the  original  requirements  were  a  contract  that  URW  fulfilled. 
Each  change  will  be  done  by  following  the  software  development  process  in  miniature,  modifying  ex¬ 
isting  work  rather  than  creating  products  from  scratch.  The  Park  &rvice  and  URW  will  first  agree  on 
the  modified  requirements.  URW  will  then  determine  bow  the  change  afreets  the  design.  It  will  then 
modify  the  code,  test  the  modified  version,  and  deliver  the  new  version  to  the  Park  Service. 

Error-free  products  are,  unfortunately,  the  exception  rather  than  the  rule.  This  is  true  of  all  products, 
requirements  and  design  as  well  as  code.  Datamation  (1994)  reported  that  California’s  Department 
of  Motor  Vehicles  committed  28  million  dollars  to  modernizing  its  computers.  The  new  facilities  were 
installed  after  6  years,  at  a  cost  of  44.S  million  dollars — and  were  junked  after  a  few  months,  because 
the  requirements  had  been  expressed  improperly.  Ince  (1988)  describes  a  U.S.  Government  Account¬ 
ing  Office  report  showing  that  over  90%  of  government-contracted  software  systems  were  unusable 
as  delivered — and  of  that  90%,  over  50%  had  reqtiirements  so  poorly  conceived  that  they  could  never 
be  used.  The  cost  of  modifying  the  software  would  have  exceeded  that  of  maintaining  the  status  quo. 

In  other  words.  Figure  2  is  something  of  an  idealization.  Royce  (1970)  termed  it  a  “waterfall  model” 
of  software  development,  since  it  depicts  work  flowing  smoothly  down  from  one  activity  to  another, 
as  water  flows  downstream  over  a  series  of  falls.  In  reality,  the  work  flows  upstream  too:  Figure  2 
should  show  arrows  from  design  to  requirements,  from  code  back  to  requirements  and  design,  and  so 
on — that  is,  from  each  downstream  activity  to  all  activities  upstream  from  it.  The  arrows  would  denote 
errors  from  a  previous  activity  caught  during  the  activity  at  the  arrow’s  tail.  People  omit  these  arrows 
to  simplify  the  picture,  claiming  that  the  arrows  shown  in  Figure  2  depict  the  most  significant  work 
flows.  The  data  in  Slide  1-6  contradict  this,  as  do  the  arguments  of  many  researchers  in  the  area 
(McCracken  and  Jackson  1982). 

2.1.2  A  Commercial  Software  Developmeot  Scenario 

When  URW  develops  a  robot  to  harvest  com  in  a  field,  it  will  follow  the  process  in  Figure  2.  The 
essential  steps  of  commercial  software  development  remain  the  same  as  for  contraaual  software 
development.  However,  the  objectives  of  the  activities  are  quite  difrerent.  This  section  gives  a  scenario 
for  commercial  software  development. 

The  Requirements  activity  differs  most.  There  is  no  customer  to  develop  the  initial  requirements 
specification  for  URW.  Instead,  URW  must  perceive  the  market  for  a  corn  harvesting  robot  and 
determine  the  characteristics  of  that  robot  themselves.  This  is  a  risky  operation.  URW  should  consult 
with  farmers  who  maybe  potential  customers,  trying  to  understand  what  they  would  like  in  a  robot — in 
fact,  trying  to  understand  if  there  really  is  a  market  for  such  a  robot.  Many  a  clever  invention  has  failed 
because  it  solved  the  wrong  problem,  because  it  had  too  much  dose  competition,  or  because  people 
turned  out  to  be  satisfied  with  what  they  had. 

The  requirements  specification  that  URW  develops  is  therefore  not  a  contract.  It  is  only  a  description 
of  the  problem  to  be  solved.  As  in  contractual  softie  development,  URW’s  engineers  use  it  to  guide 
them  during  the  Design,  Code,  and  Tbst  activities.  These  three  activities  do  not  efiffer  significantly 
from  their  counterparts  in  contractual  software  evelopment.  URW’s  goal  for  each  is  still  the  same: 
to  produce  a  product  that  is  a  solution  to  the  problem  stated  in  the  requirements.  However,  there  is 
no  customer.  An  outsider  does  not  fix  a  schedule;  URW  simply  tries  to  get  its  product  to  market 
quickly.  URW  holds  design  reviews  solely  for  its  own  benefit. 


tz 


2.  Software  Deydopment  in  iiMiustiy  “foday 


This  isolation  poses  problems  for  URW.  Software  engineers  have  long  recognized  that  the  only 
reliable  way  to  assess  software’s  correctness  is  to  try  it  in  an  environment  representative  of  its  ultimate 
market.  If.  during  development,  URW  is  beholden  to  no  customer,  how  can  it  ensure  that  its  products 
will  satisfy  customers?  URW  might  address  this  risk  by  performing  alpha  testing  and  beta  testing. 
URW  “alpha  tests”  its  product  by  using  a  preliminary  version  in  a  realistic  environment.  Engineers 
operate  the  product  as  if  it  were  the  final  version,  except  no  one  is  surprised  when  it  fails.  This  provides 
URW  with  useful  feedback  without  fear  of  alienating  customers. 

URW  follows  alpha  testing  with  beta  testing.  During  beta  testing,  URW  gives  the  alpha-tested  version 
of  its  product  to  a  few  selected  customers.  These  customers,  who  are  usually  given  some  financial 
incentive,  also  operate  the  robot  as  if  it  were  a  final  product,  again  with  the  realization  that  it  will 
probably  fail  (URW  selects  customers  who  are  potentially  interested  in  the  robot  but  whose  business 
is  not  jeopardized  by  its  failure).  Customers  report  failures  and  other  problems  to  URW.  As  URW 
receives  their  reports  and  corrects  the  problems,  it  gains  confidence  that  its  product  is  robust  enough 
to  compete  in  the  marketplace. 

In  the  Deliver  activity,  URW  does  not  deliver  the  software  to  a  customer.  It  markets  its  product 
through  an  appropriate  channel,  like  a  store  or  a  mail-order  service.  In  the  Support  activity,  it  gauges 
its  product’s  success  based  on  sales.  It  keeps  abreast  of  interest  in  the  product  and  determines  whether 
the  product  can  be  improved — often,  introducing  a  product  changes  the  environment  in  which  it  is 
used,  leading  to  new  product  opportunities.  (Wtness  the  automobile,  whose  capability  for  greater 
speed  than  the  horse  led  to  the  paved  road;  in  turn,  paved  roads  led  to  faster  automobiles.) 

In  short,  URW  is  not  directly  responsible  to  a  single  customer,  as  in  contractual  software  development. 
Although  contractual  software  tends  to  be  more  complex  than  commercial  software,  the  requirements 
for  commercial  software  are  much  harder  to  discern  and  much  more  likely  to  change.  Commercial 
companies  usually  introduce  new  products  more  frequently  than  contract-based  companies.  They 
often  have  a  comid ete  product  line — that  is,  a  set  of  related  products — so  they  can  compete  in  several 
market  niches,  l^ere  the  contractual  company  supports  only  a  single  version  of  a  product,  the 
commercial  company  must  support  each  prc^uct  in  its  product  line — not  to  mention  always  having 
to  consider  whether  to  add  new  products  to  the  line. 

2.2  PROBLEMS  WITH  SOFTWARE  DEVELOPMENT 

Section  2.1  showed  how  URW  could  follow  an  organized  software  development  process  to  create  its 
robot  control  software.  So  what  could  go  wrong?  Plenty.  In  reality,  software  development  is  just  this 
side  of  chaotic.  This  section  shows  some  of  the  reasons  why  it  is  difficult. 

•  Express^ software  requiremenis.  Requirements  written  in  English  are  usually  ambiguous:  the 
gift  of  clear  expression  is  given  to  few.  Requirements  are  often  incomplete.  One  way  to  think 
of  software  requirements  is  that  they  should  describe  all  possible  inputs  and  all  allowable  re¬ 
sponses  to  those  inputs.  No  one  has  yet  discovered  a  good  method  for  determining  whether 
requirements  written  in  English  can  describe  all  the  inputs  and  responses. 

Because  of  this  problem,  many  people  have  proposed  expressing  requirements  using 
mathematical  notations.  Such  notations  are  unambiguous  and  can  be  checked  for 
completeness — often  by  automated  tools,  which  is  especially  helpful  as  it  relieves  people  from 
performing  a  tedious,  time-consuming  chore.  However,  many  people  find  these  notations 
difficult  to  learn  and  use.  No  conclusive  evidence  exists  that  mathematical  notations  are  more 
effective  than  using  English. 
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Furthermore,  the  real  problem  with  requirements  is  not  so  much  whether  they  are  complete 
and  unambiguous,  but  whether  they  describe  the  right  problem.  Time  and  again,  experience 
has  shown  that  people  have  di£5culty  fully  grasping  a  problem — and  grasping  the  problem  is 
vital  to  producing  the  correct  solution.  This  is  well  illustrated  by  a  radar  system  the  U.S.  built 
in  Greenland  in  the  19S0s  to  detect  missiles  over  the  North  Pole.  Early  in  its  operation,  it  re¬ 
ported  the  approach  of  a  missile  the  size  of  the  moon — indeed,  it  was  the  moon,  for  the  people 
who  wrote  the  requirements  had  overlooked  that  celestial  body’s  existence.  The  engineers 
who  wrote  the  software  from  those  requirements  did  their  job  perfectly,  for  they  satisfied  their 
contractual  obligation  to  detect  high-altitude,  distant  objects.  Sometimes,  the  most  obvious 
things  are  most  evasive. 

Determining  whether  the  requirements  describe  the  right  problem  is  termed  validation. 
Validation  is  different  than  verification — determining  whether  the  software  behaves 
according  to  the  requirements.  An  organization  can  perform  verification  on  its  own,  but 
cannot  validate  software  except  by  exposing  it  to  customers.  (The  laboratory  illustrates  this 
point:  the  Validate  Requirements  step  forces  students  to  put  questions  to  their  hypothetical 
customers.)  Therefore,  validation  is  risky.  In  contractual  software  development,  customers 
may  be  forced  to  admit  they  did  not  understand  their  needs.  In  commercial  software 
development,  an  organization  faces  embarrassment  ifitspotential  customers  judge  its  product 
shoddy  or  ineffectual. 

•  Following  a  software  development  process.  Iblling  someone  they  must  write  a  software 
requirements  specification  is  one  thing.  Iblling  them  how  to  write  that  specification  is  another. 
Software  developers  understand  the  processes  they  must  follow  much  better  than  they 
understand  the  methods  for  performing  individual  activities  of  a  process.  Despite  extensive 
research  in  the  area,  specifying  and  designing  software  remains  something  of  an  art.  People 
are  told  that  an  activity  must  yield  a  certain  set  of  products,  but  are  on  their  own  as  to  how  they 
should  create  those  products.  People  have  proposed  methods,  such  as  structured  analysis 
(Marco  and  McGowan  1987)  and  object-oriented  design  (Coad  and  Yourdon  1990);  but 
methods  ease  the  problem  at  best.  They  do  not  solve  it. 

The  discussion  of  Figure  2  on  page  12  mentioned  that  it  omits  mistakes  and  therefore 
desaibes  software  development  only  partially.  This  is  another  dimension  of  the  difficulty  of 
following  a  process  exactly.  The  picture  is  supposed  to  depict  an  orderly  sequence  of  activities 
that  occur  one  at  a  time.  In  reality,  several  occur  simultaneously,  working  with  partially 
finished  and  not  fully  correct  products.  Such  a  situation  is  very  difficult  to  manage. 

•  Keepit^  requirements  and  documentation  up  to  date.  All  too  often,  when  errors  are  found  in 
requirements  or  design  documents,  no  one  bothers  to  create  a  new,  fixed  version.  Even  though 
the  enors  are  corrected,  nobody  records  the  change  except  in  the  software.  The  software  is, 
after  all,  the  goal.  As  long  as  it  behaves  as  everyone  expects,  why  bother  correcting  a  mistake 
in  the  design  document? 

The  answer  is  to  avoid  confusing  the  next  person  who  reads  the  design  document. 
Unfortunately,  software  developers  are  under  pressure  to  get  the  software  up  and  running. 
Every  change  they  make  to  the  design  document  delays  the  software.  Those  delays  cost  money, 
in  the  form  of  lost  sales  or  broken  contracts.  Companies  concentrate  on  the  end  product  and 
ignore  the  intermediate  ones.  They  forget  one  crucial  detail;  the  majority  of  effort  that  goes 
into  software  occurs  after  the  first  version  is  deployed  (Boehm  1981).  One  reason  people 
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spend  so  much  effort  during  that  time  is  because  they’re  reading  incorrect  and  out-of-date 
requirements  specifications  and  design  documents.  These  documents  were  supposed  to  help 
them  understand  the  software  and  facilitate  its  maintenance;  instead,  they  confuse. 

•  Graspii^  software  des^.  No  one  has  discovered  a  way  to  describe  software  design  clearly  and 
concisely.  Many  techniques  have  been  tried.  Industry  is  awash  with  designs  featuring  data  flow 
diagrams,  component  interface  specifications,  information  hiding  structures — the  list  goes  on. 
These  are  helpful,  unquestionably,  but  they  lack  a  key  quality:  they  do  not  present  an  inte¬ 
grated,  all-inclusive  picture  of  design.  An  architect’s  blueprints  convey  a  clear  picture  of  a 
house.  An  electrical  engineer's  circuit  diagram  shows  all  the  parts  and  interconnections  need¬ 
ed  to  build  an  electrical  system.  By  comparison,  any  of  the  software  design  notations  just  men¬ 
tioned  present  only  a  tiny  part  of  the  software’s  structure.  (This  situation  probably  reflects  the 
relative  age  of  the  professions.  Architects  have  had  several  thousand  years  to  refine  their  craft. 
Electrical  engineers  have  had  over  a  century.  Software  engineers  have  had  less  than  30  years. 
In  time,  perhaps,  software  engineers  will  discover  an  equally  descriptive  notation.) 

•  Seasting  change.  People  and  industries  like  to  stick  with  familiar  methods  and  are  reluctant  to 
adopt  new  approaches.  What  project  manager  wants  to  risk  her  or  his  project's  success  on  an 
unproven  technology?  Any  technology  is  viewed  with  skepticism  unless  it  is  proven  to  be  much 
more  effective  than  current  practice.  New  techniques  necessitate  traim'ng,  which  consumes 
valuable  time  and  increases  cost.  A  manager  will  readily  accept  change  only  when  someone 
has  shown  that  instituting  the  change  will  save  time  or  money.  Unfortunately,  studies  that 
prove  such  savings  conclusively  are  few  and  far  between  in  the  world  of  software. 

There  are  many,  many  more  reasons  why  software  development  is  so  difficult.  This  section  is  by  no 
means  comprehensive;  the  problems  discussed  are  only  those  most  closely  related  to  the  Overview  of 
Megaprogramming  Course.  Brooks  (1987)  gives  an  excellent  discussion  of  other  reasons. 

23  SUCCESS  STORIES  IN  SOFTWARE  DEVELOPMENT 

The  preceding  section  might  seem  too  gloomy.  Software  is  involved  in  many  aspects  of  our  lives.  In 
other  words,  people  can  and  do  develop  it.  So  is  developing  software  really  such  a  problem? 

The  answer  to  this  question  lies  more  in  the  economics  of  software  than  in  the  technical  problems  in 
building  it.  Everyone  knows  how  hardware  costs  have  fallen  steadily  since  the  computer  was  first 
created.  Computers  keep  getting  faster,  dieaper,  physically  smaller,  and  logically  bigger.  By  contrast, 
the  cost  of  developing  software  has  not  changed  much  over  the  past  few  decades.  A  NASA  study  during 
the  late  1980s  by  Kouchakdijan,  Green,  and  Basili  (1989)  showed  the  average  software  developer  pro¬ 
duced  24  lines  of  code  per  ^y,  a  figure  about  the  same  as  in  the  1950s.  lb  be  sure,  toda/s  software 
developers  are  building  much  larger  systems.  Then  again,  they  program  in  much  more  advanced  lan¬ 
guages,  use  interactive  terminals  instead  of  punched  cards  and  paper  tapes,  and  have  access  to  devel¬ 
opment  environments  which  would  turn  a  1950s  ptrogrammer  green  with  envy.  One  would  think  that 
these  advances  should  make  today’s  developers  much  more  productive.  In  general,  this  does  not  seem 
to  be  the  case.  Software  remains  costly  to  develop  and  maintain. 

However,  some  projects  have  produced  software  at  much  lower  cost  than  average.  Sometimes  this 
improvement  comes  from  the  people  staffing  the  project:  Boehm  (1981)  has  shown  that  individuals’ 
productivity  varies  by  a  factor  of  4  depending  on  their  skills.  Other  times,  though,  the  difference  can 
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be  attributed  to  technical  factors.  This  section  explores  some  promising  areas  of  the  state  of  the  art 
in  software  development. 

23.1  Progkamming  Languages  and  Productiyttv 

There  is  some  evidence  that  productivity  is  independent  of  the  language  or  environment  a  person  uses. 
Assume  a  person  writing  in  assembly  language  averages  24  lines  of  assembly  language  each  day.  That 
same  person  would  average  24  lines  of  Pascal  each  day,  or  24  lines  of  Ada  each  day.  If  they  were  devis¬ 
ing  a  spreadsheet,  they  would  average  24  lines  of  the  spreadsheet  language  each  day .  The  explanation 
for  this  is  that  the  human  mind  can  deal  with  a  certain  amount  of  detail  and  complexity.  Each  of  these 
languages  has  its  own  set  of  complexities  the  person  must  master. 

This  does  not  mean  language  is  unimportant.  The  24  lines  of  Pascal  are  not  equivalent  to  24  lines  of 
assembly  language;  they  are  probably  equivalent  to  several  hundred  assembly  language  instructions. 
Thus,  the  Pascal  programmer  will  be  far  more  productive  than  the  assembly  language  programmer — 
that  is,  will  build  the  same  application  quicker.  The  Ada  programme’-  will  be  better  yet,  and  the  spread¬ 
sheet  programmer  will  beat  them  all. 

Of  course,  the  spreadsheet  programmer  can  only  create  spreadsheets,  whereas  the  Pa.scal  and  Ada 
programmers  have  more  options;  none  of  them  has  the  flexibility  of  the  assembly  language  program¬ 
mer.  The  programmers  working  in  higher-level  languages  are  working  in  restricted  problem  domains . 
That  is,  they  are  dealing  less  with  characteristics  of  their  computer  and  more  with  characteristics  of 
the  problem  they  are  solving.  The  spreadsheet  programmer’s  energies  are  directed  toward  creating 
the  spreadsheet  formulas.  If  the  Pascal  programmer  tried  to  write  the  same  spreadsheet,  he  or  she 
would  also  have  to  consider  details  of  creating  and  manipulating  data  structures  to  represent  the 
spreadsheet.  These  details  are  irrelevant  in  the  spreadsheet  language;  they  are  embedded  in  the 
spreadsheet  program  itself.  The  assembly  language  programmer  would  have  to  consider  not  only 
these  details,  but  computer-specific  details  as  well — ^which  registers  to  use,  the  most  efficient  memory 
locations  for  information,  and  other  details  that  are  irrelevant  in  Pascal  because  they  are  embedded 
in  the  compiler. 

Software  development  started  with  languages  that  forced  people  to  consider  computer-related 
details.  It  has  been  moving  steadily  away  from  such  languages  ever  since.  Languages  like  Pascal  and 
Ada  are  intended  to  help  programmers  represent  algorithms.  They  are  therefore  suitable  first 
languages  because  computing  courses  begin  ty  teaching  students  algorithmic  programming  concepts. 
However,  one  of  the  audal  achievements  of  software  development  is  the  realization  that  many  parts 
of  a  program  are  best  represented  using  nonalgorithmic  constructs.  Instead,  programmers  write 
software  using  a  language  specific  to  the  domain  of  the  problem  being  solved.  This  language  is  at  a 
higher  level  than  Pascal  or  Ada.  Therefore,  the  person  who  writes  24  lines  in  this  higher-level  language 
achieves  a  result  equivalent  to  the  person  who  writes  several  hundred  lines  in  Pascal. 

This  movement  to  higher-level  languages  has  yielded  significant  productivity  increases.  The  rest  of 
Section  2.3  briefly  describes  examples  of  such  languages,  with  insights  into  how  they  arose. 

23.2  Spreadsheets 

Spreadsheets  have  become  inaeasingly  popular  i.:  the  last  decade.  They  excel  in  expressing  complex 
c^culations.  They  relieve  the  user  from  having  to  worry  about  user  interface  arrangement,  for  they 
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prttvide  a  standard.  They  allow  tabular  data  entry  and  present  data  in  that  and  a  variety  of  other 
formats,  such  as  pie  charts  and  bar  graphs. 

Spreadsheets  are  a  simple  example  of  programming  in  a  restricted  domain.  Creating  a  spreadsheet 
is,  after  all,  a  form  of  programming.  It  requires  following  a  process  not  unlike  that  for  software 
development.  The  first  task  is  to  determine  what  information  should  be  entered  into  the  spreadsheet, 
what  information  should  be  displayed,  and  the  general  appearance  of  that  information.  The  second 
task  is  to  design  formulas  that  calculate  the  results  of  the  spreadsheet.  The  third  task  is  to  implement 
that  design  by  creating  the  skeletal  spreadsheet.  The  fourth  task  is  to  verify  that  the  implementation 
works.  These  tasks,  then,  are  the  Requirements,  Design,  Code,  and  Test  activities  from  Figure  2.  The 
average  spreadsheet  user  may  not  perform  them  with  the  rigor  of  a  professional  softwaredevelopment 
company,  but  the  necessary  activities  are  still  the  same. 

There  are,  of  course,  many  things  spreadsheets  cannot  do.  They  are  inherently  two-dimensional  and 
are  not  well  suited  to  data  in  three  or  more  dimensions.  They  are  not  intended  for  esoteric  functions 
like  real-time  control  or  animation.  These  restrictions  are  deliberate.  Companies  began  developing 
spreadsheets  when  they  realized  how  much  information  in  today’s  world  lends  itself  to  tabular  presen¬ 
tation.  Many  people  were  writing  similar  programs;  no  matter  what  data  they  manipulated,  all  were 
working  with  calculations  on  two-dimensional  data. 

The  inventors  of  spreadsheets  therefore  had  two  great  insights.  First,  they  recognized  that  many 
people  were  writing  programs  to  solve  similar  problems:  all  had  tables  of  data  as  inputs  and,  as 
outputs,  they  had  that  data  plus  calculations  derived  from  the  input,  presented  in  forms  derivable  from 
the  original  two-dimensional  format.  Second,  they  realized  that  the  calculations  being  made  on  the 
input  data  did  not  require  the  power  of  a  general-purpose  programming  language,  but  could  be  made 
based  on  matrix  algebra  formulas  and  a  set  of  predefined  mathematical  functions.  The  former  insight 
told  them  what  problem  they  needed  to  solve.  The  latter  provided  them  with  an  elegant  solution.  They 
had  only  to  write  the  spreadsheet  program.  The  users  of  that  program  could  write  their  own 
“programs”  but  did  not  need  professional  software  development  skills. 

23.3  User  Interface  Generators 

Implementing  the  user  interface  has  traditionally  been  one  of  the  most  difficult  and  time-consuming 
parts  of  software  development.  In  one  study,  Boehm,  Gray,  and  Seewaldt  (1984)  discovered  that,  on 
the  average,  over  half  the  code  in  a  program  handles  its  user  interface.  This  predated  such  modern 
advancements  as  mouse-driven  input  and  graphical  windows  full  of  color  icons,  so  the  figure  is 
probably  higher  now. 

To  complicate  matters,  traditional  programming  languages  are  terrible  at  representing  details  of  user 
interfaces — and  creating  a  user  interface  is  all  about  details.  Programming  languages  are  basically 
one-dimensional,  a  long  string  of  statements,  whereas  a  graphical  interface  is  two-dimensional  and 
hierarchical.  Consider  the  following  user  interface  requirement,  which  is  fairly  straightforward  for  a 
person  to  understand; 

The  interface  is  to  be  divided  into  two  windows.  Window  1  is  to  be  3  inches  wide  and  4  inches  high.  It 
will  contain  three  buttons  and  one  window  for  text  entry.  Window  2  is  to  be  1  inch  wide  and  5  inches 
hi  It  will  contain  a  text  label  and  four  buttons.  Window  2  is  to  be  positioned  half  an  inch  to  the  right 
of  Window  1. 
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This  requirement  has  no  simple  representation  in  a  programming  language.  Even  though 
unrealistically  simple,  it  would  be  implemented  by  himdreds,  if  not  thousands,  of  lines  of  code,  when 
one  considers  the  complexities  of  handling  inputs  from  both  a  mouse  and  keyboard  (implied  by  the 
requirements  for  buttons  and  text  entry),  for  placing  the  windows,  and  for  displaying  outputs  in  them. 

Also,  the  requirement  is  not  nearly  detailed  enough.  It  says  nothing  about  the  appearance  of  ihe 
windows  and  their  contents.  What  colors  arc  the  windows?  Do  they  have  borders?  Are  the  mouse 
buttons  round  or  rectangular?  Simple  decisions  like  these  are  tedious  to  describe  as  requirements  and 
more  tedious  to  implement  in  a  programming  language.  The  person  writing  the  requirements  would 
much  prefer  to  use  a  picture  like  that  in  Figure  S,  and  the  engineers  implementing  the  interface  would 
prefer  a  more  convenient  representation  than  what  programming  languages  offer. 


Figure  S.  A  Pictorial  Representation  of  an  ^^plication’s  Interface  Requirements 

This  has  led  people  to  study  the  domain  of  user  interfaces.  The  common  problem  is  the  need  to  provide 
an  effective,  easy-to-use  interface.  People  at  first  proposed  special  interface-description  languages 
(I^^rtik  and  Penedo  1986;  Hayes  and  Szekely  1983);  but  the  real  breakthrough  came  when  someone 
realized  that: 

•  The  most  natural  way  to  describe  an  interface  is  to  draw  a  picture  of  it 

•  A  program  that  supports  drawing  a  picture  of  an  interface  has  enough  information  available 
to  generate  an  implementation  of  that  interface 

The  insights  resulted  in  tools  such  as  HyperCard,  Visual  Basic,  TAE  Plus,  and  many  others.  All  are 
based  on  the  principle  of  software  developers  constructing  the  user  interface  by  drawing  a  picture  of 
it,  then  writing  the  rest  of  the  program  in'a  standard  programming  language  which  uses  a  predefined 
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paradigm  to  obtain  inputs  and  display  outputs.  (The  paradigm  depends  on  the  tool  and  is  beyond  the 
scope  of  this  report.) 

These  tools  have  allowed  developers  to  build  software  with  remarkably  complex  interfaces  in  what 
would  once  have  been  thought  of  as  an  itKxrnceivably  short  time.  The  tools  facilitate  this  because  their 
developers  studied  the  domain  of  user  interfaces  and  discovered  how  to  describe  variations  among 
interfaces.  Their  only  drawback  is  that  they  inhibit  flexibility.  Software  developers  have  a  fixed  set  of 
input  and  output  media  (buttons,  text  entry  areas,  forms,  labels,  etc.).  In  fact,  this  is  not  really  a  draw¬ 
back,  for  using  the  tools  results  in  interfaces  with  a  common  “look  and  feel.”  Thus,  the  user  of  any  tool 
created  using  Visual  Basic  (used  to  create  Figure  S)  immediately  identifies  the  shaded  rectangles  as 
buttons  and  knows  that  pointing  the  cursor  on  one  and  pressing  the  mouse  button  invokes  the  action 
indicated  by  the  button’s  label. 

Once  again,  analysis  of  a  domain  has  yielded  an  understanding  of  common  problems  and  a  means  to 
state  solutions  to  those  problems  in  a  form  more  natural  than  a  programming  language.  For  spread¬ 
sheets,  the  solution  involved  inventing  a  new  programming  language.  Here,  the  statement  is  purely 
pictorial;  no  written  language  is  necessary.  Either  case  jxrints  toward  an  important  trend  in  software 
development.  Traditional  algorithmic  programming  languages  are  intended  to  express  algorithms;  but 
just  about  any  problem  has  nonalgorithmic aspects  best  expressed  in  a  nonalgorithmic  form.  More  and 
more,  people  are  creating  such  forms  as  a  means  to  enhance  software  development  productivity. 

23.4  Rapid  Prototyping 

Section  2.2  described  the  problems  that  stem  from  improper  requirements— requirements  that  are 
consistent  and  unambiguous,  but  desaibe  the  wrong  problem.  V^en  a  company  designs  and  imple¬ 
ments  a  solution  to  requirements,  it  makes  a  costly  investment.  If  the  requirements  are  wrong,  the 
results  can  spell  financial  doom. 

To  lessen  the  risk  of  solving  the  wrong  problem,  companies  sometimes  rapidly  create  a  prototype 
(termed  a  rapid  prototype)  from  the  requirements.  They  will  ask  a  group  of  engineers  to  aeate,  as 
quickly  as  possible,  a  rough  version  of  the  ^tem.  The  intent  is  to  simulate  the  ^stem’s  external  ap¬ 
pearance  (in  particular,  its  user  interface)  and  its  functionality.  The  company  can  then  use  the  proto¬ 
type  to  validate  whether  the  requirements  address  the  intended  problem.  If  not,  the  company  will  have 
avoided  a  large,  costly  mistake  and  will  correct  the  requirements  and  the  protore  until  they  are  con¬ 
fident  they  understand  the  problem.  They  will  then  produce  an  actual  version  of  the  system.  For  exam¬ 
ple,  URW  might  create  a  prototype  litter-gathering  robot  with  the  necessary  functionality  but  not 
robustness.  The  Park  Service  would  test  it  to  see  whether  it  was  viable — have  they  correctly  described 
the  concept  of  litter,  or  will  the  robot  snatch  a  backpacker’s  tent? 

When  a  company  creates  a  prototype,  they  do  not  intend  it  to  be  of  marketable  quality.  If  they  did, 
they  would  be  creating  an  actual  system  rather  than  a  prototype.  The  prototype  is  created  to  study 
spedfic  aspects  of  a  system,  such  as  user  interface.  Generally,  the  prototype  does  not  include  ail  the 
functionality  that  the  actual  system  will  contain;  a  subset  suffices  to  demonstrate  the  tool’s  utility. 

Prototypes  are  often  written  in  special,  very  high  level  languages  with  constructs  useful  for 
prototyping.  Such  languages  result  in  small,  easily  modifiable  programs.  This  is  important  in  rapid 
prototyping,  because  prototypes  must  change  rapidly  in  response  to  changes  in  requirements. 
(However,  the  programs  often  execute  slowly  such  is  the  price  one  pays  for  flexibility.)  The  languages 
achieve  their  power  by  incorporating  constructs  from  the  domain  in  question.  The  language  for 
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programming  Karel  the  Robot  (Pattis  1981),  used  in  the  laboratory,  illustrates  this.  Its  purpose,  from 
a  prototyper’s  perspective,  is  to  explore  movement  strategies.  It  lets  the  prototyper  ignore  such  issues 
as: 


«  How  the  sensors  operate.  The  cornfield  robot  needs  different  sensor  software  (and  perhaps 
hardware)  than  the  litter-gathering  robot.  Ears  of  com  are  more  or  less  alike  and  occur  in 
expected  places.  Litter  comes  in  many  shapes  and  sizes  and  can  be  anywhere. 

•  Details  of  motion.  The  Karel  programmer  moves  the  robot  using  the  MOVE  instruction.  The 
real  robot  has  to  account  for  startup  inertia,  maximum  velocities,  and  many  other  factors. 

URW  might  use  a  language  such  as  Karel  to  explore  issues  through  a  rapid  prototype.  The  prototype 
is  based  on  the  requirements,  so  the  customer  can  study  the  prototype  to  help  see  whether  the  require¬ 
ments  are  correct.  URW  and  the  customer  use  this  information  to  revise  the  requirements  and  build 
a  real  robot. 

Many  interesting  rapid  prototyping  systems  exist.  Some  examples  are  IDE’s  Software  through 
Pictures  and  i-Logix’s  StateMate.  It’s  worth  noting  that,  as  computers  become  faster  and  faster,  what 
was  once  an  unacceptably  slow  rapid  prototype  becomes  a  viable  software  product. 
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The  United  States  Government  is  very  concerned  about  the  software  development  problems 
described  in  Section  2.  A 1994  report  to  Congress  (Paige  1994)  stated  that  the  Department  of  Defense 
alone  had  spent  $30  billion  on  software  in  1990.  It  estimated  that  the  department’s  ejcpenditures  would 
jump  to  $42  billion  in  1995.  This  figure  does  not  include  other  branches  of  government,  such  as  NASA 
and  the  Department  of  Energy,  which  have  their  own  considerable  investments.  Nor  does  it  count  the 
commercial  market  in  software,  seen  as  one  of  the  country’s  key  assets.  It  is  no  exaggeration  to  say 
that  the  ability  to  produce  quality  software  at  a  competitive  price  in  the  world  market  may  determine 
a  country’s  economic  future.  Hartmanis  (1992)  reports  that  softw  are  is  already  more  than  5%  of  the 
United  States’  gross  national  product  and  growing — $51  billion  in  the  corporate  market  alone, 
according  to  Emigh  (1994). 

Because  it  routinely  produces  large  software  ^sterns,  the  Department  of  Defense  has  traditionally 
supported  much  of  the  country’s  computer  science  and  software  engineering  research.  Much  of  this 
research  has  been  sponsored  by  ARPA.  One  of  ARPA’s  most  famous  projects  was  the  ARPAnet,  the 
first  major  national  computer  network  and  the  source  for  many  of  the  ideas  in  today’s  Internet. 

In  1990,  to  help  fight  the  rising  cost  of  developing  and  maintaining  software,  ARPA  launched  research 
and  development  of  megaprogramming.  Megaprogramming  is  an  approach  to  software  development 
that  entails  “building  and  evolving  computer  software  component  by  component”  (Boehm  and  Scher- 
lis  1992),  rather  than  line  by  line.  Software  developers  avoid  programming  in  the  traditional  way  of 
composing  lines  of  code  into  a  program.  Instead,  they  make  use  of  existing  components;  procedures, 
functions,  packages  (in  Ada),  or  classes  (in  C+  +).  Components  are  the  result  of  previous  developwrs’ 
efforts.  Thus,  each  new  project  tries  to  capitalize  on  the  fruits  of  earlier  labors,  rather  than  creating 
programs  from  scratch. 

This  is  known  as  software  reuse.  Simply  put,  reuse  of  software  means  extracting  pieces  of  existing 
software  and  using  them  to  create  new  programs.  Such  new  programs  consist  partly  of  code  created 
expressly  for  the  new  program  and  partly  of  "reused”  code.  Many  people  today  see  reuse  as  the  key 
to  creating  cheaper,  higher-quality  software.  Using  existing,  already  working  code  has  clear 
advantages. 

Reuse  is  not  a  new  idea.  Mcllroy  (1968)  proposed  the  idea  over  two  decades  ago.  Reuse  may  even 
seem  an  intuitively  obvious  strategy  for  software  development.  In  fact,  it  has  been  around  ever  since 
the  invention  of  the  subroutine,  which  lets  people  reuse  the  same  function  in  different  places  in  their 
code. 

However,  reuse  on  a  large  scale — across  programs,  between  developers,  or  even  on  a  nationwide 
level — has  been  notoriously  difficult.  Many  projects  tty  it,  only  to  find  that  reusing  code  results  in 
lower  productivity  than  creating  it  from  saatch.  The  following  are  some  of  the  reasons  why. 
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•  People  have  different  programming  styles.  A  developer  is  usually  not  content  to  insert  a  chunk 
of  someone  else’s  code  into  her  or  his  own  program.  The  clash  between  styles  lowers  the 
program’s  readability,  which  reflects  poorly  on  the  developer.  Nobody  wants  their  code  to  be 
unreadable. 

•  Realizing  a  need  for  reuse  is  one  thing;  finding  code  to  fit  that  need  is  another.  Establishing 
“reuse  libraries”  has  proven  difficult.  People  have  tried  creating  classification  schemes  akin 
to  those  used  in  libraries;  these  schemes  categorize  software  by  function.  However,  these 
schemes  often  fail  because  developers  do  not  know  the  classification  schemes  well  enough  to 
search  for  software. 

Moreover,  searching  a  reuse  library  generally  yields  code  that  performs  a  function  similar  to, 
but  not  exactly  matching,  the  need.  Here  the  analogy  to  a  library  of  books  breaks  down.  A  soft¬ 
ware  engineer  hopes  to  find  and  reuse  a  complete  procedure;  a  scholar  looks  to  draw  material 
from  portions  of  a  book.  A  software  engineer  wants  to  use  the  procedure  unchanged;  a  scholar 
generally  recasts  the  material  in  her  or  his  own  words.  As  an  example,  a  Pascal  programmer 
who  needs  to  sort  an  array  of  records  cannot  use  a  procedure  that  sorts  an  array  of  integers. 
The  programmer  can  modify  the  procedure,  but  that  increases  the  risk  of  introducing  errors, 
subverting  one  of  reuse’s  advantages.  TTie  problem  of  exactly  matching  needs  grows  with  the 
complexity  of  the  need  and  strategies  for  dealing  with  it  (e.g.,  Ada  generic  parameters,  C+  + 
inheritance  hierarchies)  become  increasingly  less  effective. 

•  Software  developers  have  an  unfortunate  tendency  to  trust  their  own  code  and  mistrust 
eveiyone  else’s.  This  attitude,  termed  the  not-invented-here  or  NIH  syndrome,  stems  from 
their  experiences  with  other  developers’  buggy  software  and  from  their  unshakable  faith  in  the 
supremacy  of  their  own  programming  style.  Given  the  choice  between  writing  something 
themselves  or  taking  someone  else’s  code  and  verifying  that  it  works,  they  claim  the  former 
will  wind  up  being  simpler.  They  forget  that  their  attitude  toward  others’  code  is  the  same  as 
others’  attitude  toward  their  code.  Weinberg  (1971)  reacted  strongly  against  this  attitude  and 
coined  the  phrase  “egoless  pre^amming”  as  the  ideal  that  developers  should  adopt. 

•  The  software  world  has  adopted  relatively  few  standards,  and  standards  are  what  has  allowed 
reuse  to  succeed  in  other  fields.  In  the  United  States,  electrical  sockets  deliver  120  volts  of 
current  alternating  at  60  cycles  per  second.  For  this  reason,  televisions  plug  into  the  same 
sockets  as  miaowave  ovens.  Their  manufacturers  do  not  have  to  anticipate  arbitrary  electrical 
power  supplies,  because  the  country  has  adopted  a  siiigle  standard.  When  a  company  designs 
an  electrical  appliance,  its  engineers  can  reuse  an  existing  design  for  the  power  supply. 

By  comparison,  few  software  standards  exist.  There  are  some  exceptions.  The  X  Window 
System  (Scheifler  and  Gettys  1986)  provides  a  standard  for  client-server  software. 
DOD-2167-A  (Department  of  Defense  1988)  is  a  standard  for  documentation  to  accompany 
the  software  development  process.  The  ^tems  in  Section  23.3  define  a  standard  look  and  feel 
for  user  interfaces.  However,  no  one  has  yet  found  a  standard  that,  when  followed,  helps 
people  intercormect  two  arbitrary  software  components. 

ARPA  recognized  these  difficulties.  Megaprogramming,  therefore,  tries  a  specific  angle  to  help  make 
reuse  work.  It  presumes  a  product  line  approach.  That  is,  organizations  must  consider  themselves  to 
be  manufacturers  of  a  line  of  software  products,  not  producers  of  a  single  program.  In  fact,  this  usually 
involves  only  a  change  of  attitude  and  not  one  of  pr^uction.  If  a  company  sells  commerdal  software 
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that  runs  on  more  than  one  type  of  computer — and  most  major  ones  do — ^it  sells  a  product  line  and 
not  a  single  product.  Its  engineers  must  niake  different  design  decisions  based  on  the  target  computer. 
It  must  package  the  product  according  to  the  installation  procedures  appropriate  to  each  computer. 
It  must  create  separate  documentation  for  each  package. 

A  contractual  company  does  not  operate  this  way;  it  creates  software  for  a  customer’s  computer. 
However,  contractual  companies  acquire  a  reputation  in  specific  areas  and  do  business  mainly  in  those 
areas.  A  succession  of  contracts  in  an  area  makes  a  product-line  view  desirable.  Suppose  URW  wins 
three  contracts:  one  for  a  litter-oollectii^  robot  for  the  U.S.  Park  Service,  a  second  for  a 
search-and-rescue  robot  for  the  Alaska  National  Guard,  and  a  third  for  a  mineral-prospecting  robot 
for  the  U.S.  Department  of  the  Interior.  Although  the  robots  will  differ  in  many  ways,  they  will  also 
share  many  important  similarities.  URW*s  ability  to  capitalize  on  those  similarities — especially  by 
reusing  software  ff  om  one  robot  to  the  next— will  determine  how  cheaply  it  can  build  each  robot  and, 
hence,  how  competitive  it  can  be.  In  other  words,  if  a  contract-oriented  company  views  its  products 
as  a  product  line  over  the  course  of  several  contracts,  it  can  reuse  software. 

Megaprogranuning  demands  one  characteristic  of  software  product  lines:  that  all  products  in  the  line 
share  similarities.  This  is  not  necessarily  the  standard  use  of  the  term  “product  line.”  A  company  in 
the  tool  business  might  call  its  home  construction  and  repair  tools  a  product  line.  This  could  encom¬ 
pass  everything  fi'om  a  screwdriver  to  an  air  compressor.  Megaprogramming  employs  the  product  line 
concept  to  speed  up  software  development  bas^  on  similarities.  Similarities  between  a  saewdriver 
and  an  air  compressor  are  not  immediately  envious.  Therefore,  such  a  product  line  would  be  of  no 
value  in  the  megaprogramming  approach. 

ARPA  believes  that  megaprogranuning  holds  great  promise  for  improving  America’s  ability  to 
develop  software.  It  has  allocated  considerable  research  and  development  funding  for 
megaprogranuning.  ARPA  first  considered  megaprogranuning  an  advanced  software  engineering 
technique,  best  learned  by  seasoned  software  developers.  After  further  consideration,  however,  its 
proponents  realized  that  many  aspects  of  megapre^amming  were  elementary  and  required  no 
experience.  ARPA  also  came  to  believe  that  merging  these  concepts  into  the  early  computing  courses 
could  present  students  with  a  more  realistic  picture  of  software  development.  Students  would, 
therefore,  be  better  prepared  to  enter  the  work  force  as  skilled  software  developers.  Even  those 
destined  for  graduate  studies  or  academic  careers  would  benefit  from  knowledge  of 
megaprogramming,  for  they  would  have  a  fuller  understanding  of  the  problems  in  software 
development  than  today’s  graduates. 

ARPA  therefore  initiated  the  Megaprogramming  Curriculum  Project.  Its  ultimate  goal  is  to  change 
the  computing  curriculum  to  include  megaprogranuning  concepts.  If  it  is  successful,  students  will 
graduate  knowing  how  to  perform  megaprogramming  and  will  think  of  software  reuse  across  a  product 
line  as  a  natural  and  obvious  way  to  develop  software — quite  in  contrast  to  toda/s  start-ffom-scratch 
mentality  (see  Section  5).  This  report  and  the  Overview  of  Megaprogramming  Course  are  the  early 
products  of  the  project:  an  introduction  to  megaprogranuning  concepts  and  a  rationale  for  their  use. 
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So  far  the  emphasis  in  this  paper  has  been  on  the  problems  facing  today’s  software  developers.  Section 
3  discussed  how  ARPA  has  recognized  the  problems  and  advocated  megaprogramming  as  a  solution. 
Section  3  stated  that  megaprogramming  is  a  product-h'ne  approach.  It  did  not  actually  define 
megaprogramming,  though,  and  the  purpose  of  this  section  is  to  do  so. 

The  lecture  defines  megaprogramming  (see  Slide  1-8)  but  never  gives  a  complete  definition.  Indeed, 
the  notes  for  Slide  4-12  end  by  asking  students  their  opinions  on  the  term’s  meaning.  The  definition 
in  this  section  is  deeper,  not  being  confined  to  the  format  of  slides  and  an  accompanying  page  of  notes. 
It  provides  a  fuller  explanation  of  the  key  concepts  and  underlying  issues.  The  material  might  be  too 
detailed  for  an  introductory  lecture,  but  understanding  it  will  give  greater  confidence  when  discussing 
megaprogramming. 

This  section  begins  by  discussing  domains,  a  foundation  of  megaprogramming.  It  then  uses  domains 
to  present  the  definition  of  megaprogramming;  this  is  accomplished  by  first  presenting  a  scenario  of 
a  company  perfarming  megaprogramming,  then  tying  together  concepts  from  the  scenario  to  give  an 
aaual  definition  of  megaprogramming.  'The  section  concludes  by  showing  how  megaprogramming 
improves  an  organization’s  ability  to  develop  software. 

4.1  DOMAINS 

Section  3  mentioned  that  megaprogramming  is  a  product-line  approach  to  software  development,  but 
also  pointed  out  that  the  definition  for  “product  line”  was  not  necessarily  the  standard  one.  In  mega- 
prpgramming,  all  products  in  the  line  must  share  similarities.  Understanding  this  concept  is  vital  to 
understanding  megaprogramming. 

The  product-line  approach  in  megaprogramming  is  based  on  the  concept  of  domains.  Section  2 
introduced  domains,  but  informally.  The  definition  on  Slide  2-4  omits  some  subtleties.  Here  is  the 
complete  story.  It  is  not  a  simple  story,  it  requires  understanding  several  other  concepts,  which  will 
be  introduced  presently. 

4.1.1  Concepts  OF  Domains 

First,  it  may  help  to  understand  what  a  domain  is  not,  since  the  word  is  in  common  use.  A  decidedly 
informal  and  unscientific  survey  of  the  Consortium’s  employees  revealed  that  most  thought  domain 
meant  "home.’’  This  meaning  is  not  relevant  to  megaprogramming. 
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Webster’s  gives  six  definitions  for  the  word  “domain."  Two  are  of  interest; 

1.  A  sphere  of  influence  or  activity. 

2.  The  set  of  elements  to  which  a  mathematical  or  logical  variable  is  limited,  specifically  the  set 
on  which  a  function  is  defined.  (This  is  the  definition  used  in  mathematics.) 

Actually,  the  concept  of  a  domain  in  software  development  has  little  to  do  with  the  use  of  the  word 
as  it  relates  to  functions.  When  mathematicians  speak  of  function’s  domain  and  range,  they  are  refer¬ 
ring  to  sets  of  entities,  such  as  integers,  real  numbers,  or  strings.  They  are  concerned  with  the  relation¬ 
ship  between  two  sets.  When  software  developers  speak  of  a  domain,  they  are  interested  primarily  in 
the  set  for  its  own  sake,  not  its  relationship  to  another  set.  In  software  development,  a  domain  has  no 
associated  range.  There  is  no  mapping  from  domains  to  anything  else.  Software  developers  concern 
themselves  with  what  makes  up  a  domain  and  why. 

So  why  give  the  second  definition?  The  reason  is  that  when  discussing  software,  people  speak  of 
domains  as  if  they  were  a  set  of  elements.  Slide  2-4  mentions  “the  domain  of  robots.”  In  the  Unit  3 
laboratory,  students  create  software  in  the  domain  of  robot  control  programs.  Humans,  it  seems,  feel 
a  need  to  assign  short  labels  to  large  areas.  Referring  to  the  totality  of  concerns  would  be  more 
descriptive,  but  nobody  has  found  a  simple  way  to  do  it;  instead,  they  assign  a  label  that  partially 
describes  the  domain.  So  software  developers  face  the  same  puzzle  Alice  faced  in  Lewis  Carroll’s 
Through  the  Looking  Glass: 

“You  are  sad,"  the  Knight  said  in  an  anxious  tone;  “let  me  sing  you  a  song  to  comfort  you.” 

“Is  it  very  long?”  Alice  asked,  for  she  had  heard  a  good  deal  of  poetry  that  day. 

“It’s  long,”  said  the  Knight,  “but  very,  VERY  beautiful.  Everybody  that  bears  me  sing  it— either  it 
brings  the  TEARS  into  their  eyes,  or  else — 

“Or  else  what?”  said  Alice,  for  the  Knight  had  made  a  sudden  pause. 

“Or  else  it  doesn’t,  you  know.  The  name  of  the  song  is  called  ‘HADDOCKS’  EYES.’  ” 

“Oh,  that’s  the  name  of  the  song,  is  it?”  Alice  said,  trying  to  feel  interested. 

“No,  you  don’t  understand,"  the  Knight  said,  looking  a  little  vexed.  “That’s  what  the  name  is  CALLED. 

The  name  really  IS  THE  AGED  AGED  MAN.’  ” 

“Then  I  ought  to  have  said  That’s  what  the  SONG  is  called?’  ”  Alice  corrected  herself. 

“No,  you  oughtn’t:  that’s  quite  another  thing!  The  SONG  is  called  ‘WAYS  AND  MEANS;’  but  that’s 
onity  what  it’s  CALLED,  you  know!” 

“Wtell,  what  IS  the  sottg,  then?”  said  Alice,  who  was  this  time  completely  bewOdered. 

“I  was  coming  to  that,”  the  Knight  said.  “The  song  really  IS  ‘A-SITI'ING  ON  A  GATE;’  and  the  tune’s 
my  own  invention.” 

There  may  be  maiQt  ways  to  label  a  song,  but  they  don’t  necessarily  describe  what  it  IS.  Instead,  they 
describe  some  facet  of  it  (all  the  titles  are  phrases  from  the  song).  Similarly,  there  are  many  ways  to 
label  a  domain.  The  one  used  most  often  is  the  one  describing  the  domain’s  most  tangible,  visible 
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product.  Fbr  example,  URW  produces  and  sells  robots,  so  its  engineers  would  s[>eak  of  “the  domain 
of  robots.”  Yet  the  user  manuals,  requirements  specification,  and  design  documents  that  URW 
produces  give  a  fuller  explanation  of  the  domain  than  ai^one  could  glean  from  examining  URWs 
robots  (how  many  people  can  operate  a  personal  computer  without  ever  consulting  its  user  manual?) . 
So  user  manuals,  requirements  specifications,  and  design  documents  are  equally  part  of  the  domain, 
for  they  describe  what  is  in  the  domain  at  least  as  well  as  does  the  set  of  robots  URW  builds. 

Defining  a  domain  as  a  sphere  of  isfloence  or  activity  is  more  accurate  v^en  discussing 
megaprogramming  (Slide  24  uses  the  phrase  “wcll-defrned  area”).  Unit  4  hints  at  the  reasons  why. 
When  domain  engineers  define  a  domain,  they  study  their  company’s  activities  to  determine  nfrat 
programs  are  in  the  domain  (Webster’s  second  definition  again).  But  in  software  engineering,  a 
domain  is  more  than  just  an  arbitrary  collection  of  programs.  If  two  programs  are  to  be  part  of  the 
same  domain,  then  ty  definition  they  must  have  some  similarities.  (This  is  another  reason  why 
definition  2  is  not  adequate.  The  domain  of  a  function  can  be  an  arbitrary  set.)  Domain  engineers, 
therefore,  need  criteria  to  determine  whether  two  programs  are  related. 

They  derive  these  criteria  by  thinking  of  their  company’s  products  as  solutions  to  the  problems  their 
customers  face.  Tb  define  the  criteria,  then,  a  business  must  first  understand  its  customers’  problems. 
The  details  of  problems  depend  on  a  company’s  business.  Some  are  technical.  A  chemical  engineering 
company  might  develop  software  to  control  its  chemical  production — opening  and  closing  valves, 
monitoring  fluid  flow,  and  checking  pipe  pressures.  The  software  will  be  a  morass  of  thermodynamic 
equation  calculations.  An  aerospace  company  might  develop  satellite  control  software,  full  of 
navigational  and  positional  computations. 


4.1.2  Infuuence  of  Domain  on  Software  Development 

The  technical  problems  mainly  influence  software  design.  Other  problems  arc  not  technical  and  tend 
to  exert  more  influence  on  what  the  software  does  (the  difference  between  requirements  and  design, 
discussed  in  Section  2.1).  Before  deciding  how  to  manufacture  chemicals,  a  company  must  first  decide 
what  chemicals  to  manufacture.  Before  writing  satellite  control  software,  a  company  must  determine 
what  types  of  satellites  it’s  going  to  control.  In  other  words,  a  company  should  dedde  its  market  before 
it  starts  developing  products.  This  decision  bounds  the  set  of  problems  domain  engineers  must  define 
and  solve. 


But  companies  do  not  always  use  domain  engineering  (i.e.,  a  megaprogramming  approach)  to  solve 
problems.  They  only  do  so  when  they  expect  to  set  up  a  product  line.  Figure  6  helps  show  why.  When 
a  company  first  realizes  the  potential  for  sales  in  a  market,  it  establishes  a  business  area — that  is,  an 
organization  tasked  to  conduct  business  in  that  market.  This  organization  will  study  the  market  and 
determine  the  problems  to  be  solved  for  business  to  succeed  in  that  market.  The  organization  will  then 
propose  solutions.  It  may  decide  that  the  most  effective  way  to  compete  in  the  market  is  to  offer  aprod- 
uct  line.  If  so,  it  will  define  the  scope  of  the  product  line:  the  exact  set  of  products  to  bring  to  market. 
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Hgure6.  Reiationdxipc^Marl^t  to  Domain 

It  must  then  determine  the  most  effective  way  to  manufacture  all  the  products  in  the  line.  If  the 
products  all  seem  similar,  the  company  will  conceive  of  them  as  a  domain  and  use  domain  engineering 
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techniques  to  implement  process  support  (see  Slide  4-2).  Process  support  is  whatever  hel|;»  the 
company  manufacture  products  in  the  product  line.  It  consists  of  three  parts: 

•  A  product  family.  This  is  the  set  of  programs  (and  related  entities,  like  the  requirements  and 
design)  that  are  in  the  domain. 

•  The  application  ei^necring  process  for  producing  products.  This  is  what  Slides  3-S  through 
3-7  desaibe  for  the  robot  domain.  The  application  engineering  process  tells  how  to  use  the 
product  family  to  build  products. 

•  Software  to  support  using  the  ai^ication  engineering  process.  The  software  for  the  Unit  3 
laboratory  is  an  example  of  such  software.  It  references  files  in  the  directory  hierarchy  rooted 
at  GEN\AC  (relative  to  the  directory  where  the  laboratory  is  loaded);  these  files  constitute 
the  product  family  of  robot  control  software. 

Based  on  these  concepts,  a  domain  can  be  deGned  as  process  support  for  a  product  line. 

Note  that  the  lecture  notes  do  not  use  the  term  "product  family,'’  instead  referring  to  a  domain  as  if 
it  were  a  produa  family.  This  is  a  simplification.  A  product  family  is  one  facet  of  a  domain.  Under¬ 
standing  this  is  important  to  understanding  megaprogramming.  However,  it’s  mainly  relevant  during 
domain  engineering;  it’s  therefore  not  important  for  the  course,  which  covers  domain  engineering 
lightly. 

As  it  builds  the  product  family,  the  organization  takes  advantage  of  the  similarities  among  solutions 
to  problems  in  the  domain.  'This  helps  it  build  all  product-line  members  more  efficiently  than  if  it  tried 
to  build  them  all  separately.  This  strategy  only  works  when  there  are  many  similarities  among  mem¬ 
bers  in  the  product  line.  The  home  construction  tools  example  in  Section  3  illustrates  a  product  line 
that  is  not  a  product  family.  It  cannot  be  studied  as  a  domain,  so  building  process  support  is  not  an 
appropriate  strategy  for  manufacturing  home  construction  tools. 

Note  that  the  organization  does  not  actually  build  products  when  it  builds  the  product  family.  It  builds 
the  capability  to  build  any  product  in  the  product  line.  Tb  understand  this,  consider  an  automobile 
manufacturing  company — indeed,  even  a  single  model  within  a  company.  Even  a  single  model  has 
many  variations,  such  as  its  color  and  the  factory  installed  options.  The  company  does  not  want  a  sepa¬ 
rate  production  procedure  for  each  possible  variation,  though.  Imagine  how  much  more  automobiles 
would  cost  if  red  and  blue  cars  had  to  be  made  completely  separately.  Therefore,  the  company  builds 
an  assembly  line  capable  of  incorporating  such  minor  variations.  This  assembly  line  is  the  product  fam¬ 
ily.  The  company  uses  the  product  family  (assembly  line)  to  build  products  (automobiles).  In  this  way 
it  performs  its  business  more  effectively,  making  itself  adaptable  to  a  wider  market. 

By  doing  domain  engineering,  a  company  commits  itself  to  activities  in  a  well-defined  area.  This  is  the 
relevance  of  Webster’s  second  definition  of  domain.  That  defim'tion  is  still  not  wholly  accurate,  since 
it  does  not  imply  similarities,  but  it  is  conceptually  significant. 

In  summary,  defining  a  domain  through  domain  engineering  shows  an  organization  how  to  satisfy  a 
variety  of  customers  in  a  market.  That  market  also  helps  the  organization  understand  why  and  how 
the  domain  will  evolve  in  the  future.  And  domains  do  evolve,  just  as  individual  programs  evolve.  Slide 
1-4  shows  Operation  and  Maintenance  as  part  of  the  big  picture  of  software  development.  It  omits  the 
simple  fact  that,  by  the  time  software  is  finally  retired,  the  money  spent  on  maintenance  has  dwarfed 
that  spent  during  the  initial  development.  Most  software  development  occurs  during  maintenance. 
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Evolution  of  products  has  many  causes.  The  most  obvious  is  that  companies  want  initial  development 
to  be  as  quick  as  possible,  whereas  they  hope  their  product  will  be  salable  for  a  long  period — all  of 
which  is  termed  “maintenance.*’  Whatever  the  cause,  it  follows  that  software  developers  must  be  able 
to  modify  software:  to  redefine  the  problems  and  solutions  in  the  domain.  People  redefine  problems 
by  understanding  the  market,  predicting  changes  in  it,  and  defining  how  products  should  evolve  in 
response  to  those  changes. 

4.2  DEFINITION  OF  MEGAPROGRAMMING 

Now  that  domains  have  been  explained,  it  is  time  to  present  a  definition  of  megaprogramming.  This 
section  will  give  a  better  feeling  for  what  megaprogramming  is  and  how  it  affects  an  organization. 

4.2.1  A  Megaprogramming  Scenario 

Consider  URW  again.  Section  2.1  presented  contractual  and  commercial  software  development 
scenarios  for  URW.  The  practices  in  these  scenarios  are  typical  of  how  many  companies  develop 
software  today.  Section  2.2  discussed  reasons  why  DEW’S  practices  might  cause  difficulties.  Suppose 
URW  adopts  megaprogramming.  What  will  it  do  differently? 

Many  of  DEW’S  problems  stem  from  the  independence  among  its  projects.  The  two  projects  in 
Section  2.1  operated  as  if  they  were  parts  of  different  companies.  They  did  not  share  information — at 
least,  not  in  any  formal,  documented  manner  that  could  be  presented  in  the  scenarios.  This  is  despite 
the  many  similarities  that  probably  exist  between  the  two  projects.  The  robots  may  be  different,  but 
they  are  part  of  the  same  domain.  So  URW  decides  that  its  product  line  is  a  produa  family  and  opts 
to  build  process  support  to  help  it  manufacture  robots  more  efficiently. 

Tb  achieve  this,  URW  must  reorganize  itself  into  something  resembling  Slide  4-12.  URW  will  create 
a  separate  domain  engineering  group.  This  group  is  responsible  for  creating,  monitoring,  and  improv¬ 
ing  the  process  support.  Each  time  URW  receives  an  order  for  a  robot,  it  will  start  an  application  engi¬ 
neering  project,  as  before.  The  difference  is  that  the  application  engineering  project  will  use  the 
process  support.  Using  it  entails  following  a  special,  doroain-spedfic  application  engineering  process 
like  that  in  Slide  3-6,  not  a  general  one  like  in  Figure  2. 

The  course  laboratory  illustrates  application  engineering  when  following  such  a  process,  so  it  won’t 
be  discussed  here.  The  important  point  is  that  it’s  a  process  tailored  to  the  domain.  Application  engi¬ 
neers  develop  software  mainly  by  thinking  about  problems  in  the  domain.  They  think  about  such  prob¬ 
lems  in  any  software  development  process — in  Section  2.1,  they  developed  a  software  requirements 
specification,  which  amounts  to  the  same  thing.  However,  the  application  engineers  using  process  sup¬ 
port  don’t  develop  the  complete  requirements  spedfication.  They  only  describe  how  the  family  mem¬ 
ber  they  want  to  build  differs  from  other  family  members.  This  is  a  small  part  of  the  whole 
spedfication,  so  URW  saves  time  and  effort.  Furthermore,  the  application  engineers’  difficult  work 
ends  once  they  have  desaibed  the  problem.  The  rest  of  software  development  is  mechanical,  derived 
entirely  from  the  problem  statement. 

This  strategy  works,  as  the  notes  for  Slide  3-3  mention,  because  application  engineers  are  experts  in 
the  domain.  They  possess  an  intuitive  understanding  of  the  properties  common  to  all  family  members. 
Th^  understand,  or  are  able  to  determine,  the  implications  of  a  variation  among  family  members. 
Fbr  this  reason.  Unit  3  tries  hard  to  make  students  semiexperts  in  the  robot  domain  prior  to  their 
laboratory  experience. 
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It’s  worth  noting  that,  in  reality,  URW’s  af^ication  engineers  could  not  generate  complete,  working 
software  automatically  based  on  their  pr(A>lem  statement.  The  process  support  is  only  as  good  as 
URW’s  domain  engineers’  predictive  abilities.  Customers  will  almost  certainly  demand  variations 
URW  had  not  anticipated.  'Ibshiba,  a  Japanese  company  that  builds  power  plants,  instituted  a  form 
of  megaprog,  amming  and  found  they  could  generate  about  70%  of  their  software  automatically.  Since 
each  power  plant  required  over  one  million  lines  of  code,  they  reaped  incredible  savings— but  they 
still  had  to  develop  300,000  lines  of  code  for  each  new  project.  URW’s  engineers  would  face  similar 
situations.  To  keep  the  introduction  to  megaprogramming  simple,  the  course’s  laboratory  glosses  over 
this  point  and  generates  100%  of  the  softwue  for  the  students. 

j^rplication  engineers  follow  a  domain-specific  process.  Domain  engineers  do  not.  They  use  a 
software  development  process  quite  different  from  either  the  application  engineering  process  or  the 
one  in  Figure  2.  The  objective  of  this  process  is  to  create,  field,  and  enhance  a  product  line — what  the 
slides  term  process  support.  Figure  7  shows  this  process;  the  text  following  Figure  7  explains  it,  activity 
by  activity. 

•  Domain  Management.  URW  begins  domain  engineering  by  starting  with  the  Domain 
Management  activity.  Here,  URW  decides  what  process  support  it  wants  to  build.  This  is  a 
critical  business  decision.  It  determines  what  markets  URW  will  try  to  capture.  The  result  of 
this  decision,  expressed  as  the  domain  plan,  determines  URW’s  business  direction  for  the  next 
several  years.  The  domain  plan  guides  domain  engineers  in  all  their  other  activities  (hence  the 
nested  boxes). 

•  DonuunAnatysis.  URW  begins  the  Domain  Analysis  activity  after  making  the  decision  on  what 
process  support  to  build.  The  goal  of  Domain  Analysis  is  to  produce  a  specification  of  the  pro¬ 
duction  line.  URW  will  task  a  group  of  experts  in  the  domain  of  robots  (domain  engineers)  to 
study  the  problems  that  robots  must  solve  and  to  uncover  the  similarities  and  differences 
among  these  problems.  The  domain  engineers  will  use  this  information  toward  two  ends: 

—  Tb  describe  the  application  engineering  process. 

-  lb  specify  the  properties  of  a  solution  to  any  of  the  problems  in  the  domain.  That  is, 
they  have  described  a  family  of  problems.  They  describe  a  family  of  solutions,  one  solu¬ 
tion  per  problem,  and  desaibe  the  relationship  between  the  two  families.  Thus,  if  an 
application  engineer  describes  a  problem,  the  domain  engineer  has  provided  a  means 
to  identify  a  solution. 

•  Domain  Definition.  Domain  en^neers  produce  the  specification  in  two  steps.  During  the  first, 
the  Domain  Definition  activity,  they  produce  an  informal  desaiption  of  the  domain. 

•  Domain  Spec^ication.  Domain  engineers  use  the  domain  definition  during  the  Domain 
Specification  activity,  when  they  produce  the  more  rigorous  domain  specification.  The  domain 
definition  is  deliberately  short  on  details;  the  domain  specification  is  sufficiently  precise  to 
serve  as  a  requirements  specification.  The  domain  definition  is  small  and  focuses  on  concepts; 
the  domain  specification  is  much  larger  and  lets  a  domain  engineer  answer  any  question  about 
the  problems  and  solutions  in  the  domain.  This  paradigm  of  refining  an  informal  description 
is  a  common  engineering  design  strategy. 

This  has  briefly  described  the  process  domain  engineers  follow  to  aeatc  the  products  shown  in 
Slides  4-3  through  4-10.  Note  that  the  domain  engineers  have  not  created  any  software  at  this  point. 
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They  have  only  described  problems  that  software  they  create  must  solve,  and  have  described  the 
architecture  of  proposed  solutions. 


Domain  Knowledge 


Figure  1.  *The  Domain  Engineering  Process 


•  Domain  Implementation.  With  the  domain  specification  in  hand,  domain  ei  pincers  begin  the 
Domain  Implementation  activity.  Here,  they  build  the  process  support  that  application  engi¬ 
neers  will  use.  This  involves  building  the  product  family,  defining  the  uppiication  engineering 
process,  and  developing  the  software  to  assist  in  process  support.  In  more  detail: 


-  The  product  family  consists  of  reusable  software  components.  These  are  based  on  the 
architecture  developed  during  domain  analysis.  The  domain  engineers  will  implement 
a  software  component  for  each  box  in  the  architecture  (see  Slide  4-6).  Note  that  the 
architecture  itself  is  not  part  of  the  software,  any  more  than  a  building’s  architecture 
is  part  of  a  building. 
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-  The  application  engineering  process  describes  the  process  for  specifying  requirements 
(precisely  stating  the  problem,  see  Slide  4-5)  and  thegeneration  procedures  (see  Slide 
4-11).  Generation  procedures  are  an  exact  desaiption  of  the  relationship  between  a 
problem  and  its  solution.  Application  engineers,  once  they  have  stated  a  problem,  will 
use  the  generation  procedures  to  produce  the  software. 

-  Developing  the  software  that  automates  the  process  support  is  a  miniature  software 
development  process  in  its  own  right.  URW  tries  to  determine  which  activities  of  the 
application  engineering  process  are  most  likely  to  introduce  errors.  It  then  studies 
those  activities  and,  where  practical,  automates  them.  In  the  laboratory,  adapting  the 
reusable  software  components  to  satisfy  a  particular  problem  statement  is  one  of  the 
most  difficult  tasks  for  humans  to  perform.  It  is  not  a  complex  task,  just  a  tedious 
one — describing  how  to  do  it  manually  would  sometimes  require  hundreds  of 
instructions.  It  has  therefore  been  automated. 

■  Domain  Vetification.  Domain  engineers  then  determine  whether  the  process  support  satisfies 
the  domain  specification.  This  is  analogous  to  testing  in  a  conventional  project,  but  domain 
engineers  must  see  if  each  problem  in  the  domain  has  a  correct  solution,  rather  than  checking 
a  single  solution  against  a  single  problem. 

•  Project  Support.  In  addition  to  these  activities,  the  domain  engineering  group  acts  as  a  support 
organization  with  respect  to  application  engineering  projects.  Domain  engineers  are  responsi¬ 
ble  for  setting  up  the  production  line  and  helping  application  engineers  use  it.  They  are  also 
responsible  for  noting,  and  correcting,  deficiencies  in  the  process  support. 

The  result  of  all  this  is  that  URW  has  launched  a  set  of  concurrent  iterative  processes.  Domain 
engineering  is  not  a  simple  progression  of  steps,  as  in  Figure  2.  The  results  of  domain  engineering  feed 
back  into  the  initial  activities  of  domain  engineering  as  domain  engineers  evolve  the  domain.  Thus, 
each  domain  engineering  iteration  results  in  'mproved  process  support.  URW  can  better  position 
itself  for  future  sales  as  a  result  of  this  effort.  At  the  same  time,  an  application  engineering  project 
responds  to  its  changing  customer  needs — ^whether  that  of  an  individual  customer  or  of  an  entire 
marketplace — by  refining  its  problem  statement  and  building  new,  improved  versions  of  a  product. 
Each  application  engineering  iteration  results  in  a  new  product. 

4.2.2  What  Is  Megaprogramming? 

URW  has  used  megaprogramming  to  develop  products.  That  is,  it  has  achieved  a  capability  to  sell  a 
variety  of  products  in  a  changing  marketplace  by  doing  the  following: 

•  Appealing  to  a  wide  customer  market  by  thinking  in  terms  of  a  product  line  rather  than  a  single 
product 

•  Realizing  that  there  are  many  similarities  among  its  products  and  taking  the  time  to  study 
these  similarities 

•  Exploiting  these  similarities  by  implementing  process  support 

When  a  company  takes  these  three  actions,  it  is  practicing  a  megaprogramming  approach  to  software 
development. 
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There  are  four  key  concepts  in  megapro^amnung; 

■  Product  families.  A  family  is  a  set  of  things  that  are  sufficiently  similar  that  it  is  worthwhile  to 
understand  the  common  properties  of  the  things  before  considering  special  properties  of  spe¬ 
cific  instances.  Domain  engineers  think  in  terms  of  product  families,  rather  than  in  terms  of 
individual  products.  By  doing  so,  they  anticipate  a  range  of  needs.  This  helps  a  company  like 
URW  plan  for  the  future  as  well  as  the  present.  It  has  helped  companies  iike  Microsoft  Corpo¬ 
ration  make  such  products  as  Word  and  Excel  work  on  a  range  of  computers.  (That  is,  there 
are  several  versions  of  Word,  each  of  which  cnerates  on  a  different  platform,  ^ch  version  is 
a  product.  The  set  of  all  versions  is  a  p  It’s  also  important  to  someone  develop¬ 
ing  software  for  their  personal  compute!  ^uive  to  understand  the  nature  of  the  problem 

at  hand. 

•  Iterative  Processes.  Any  organization,  software  or  otherwise,  should  expect  to  use  iterative 
processes.  Experience  is  the  best  teacher,  says  the  old  saw,  and  has  proven  the  only  reliable 
way  to  diagnose  trouble  spots  in  a  production  capability.  (Henry  Ford  first  had  lines  of  workers 
moving  between  stationary  cars,  rather  than  cars  moving  between  stationary  workers.)  Quality 
software  is  inevitably  produced  only  through  successive  iterations  of  specification,  design,  and 
implementation  activities.  The  company  or  individual  that  uses  an  iterative  process  recognizes 
the  difficulty  of  writing  the  requirements  for  a  useful  product  without  having  built  and  used 
it,  or  of  keeping  up  with  ever-changing  technology.  Companies  that  write  operating  systems 
understand  this  need  very  well.  As  of  this  writing,  Microsoft  Corporation  has  produced  six 
versions  of  DOS,  Apple  Ojmputer  seven  versions  of  its  Macintosh  operating  system. 

•  Specification.  A  specification  is  a  precise  description  of  the  properties  needed  of  some  entity, 
such  as  a  program.  Of  particular  interest  are  specifications  of  requirements.  If  the  require¬ 
ments  specification  really  is  precise — not  an  informal  description  in  English,  but  something 
akin  to  the  set  of  decisions  in  the  laboratory — ^then  it  can  be  used  as  the  input  to  a  generation 
procedure,  from  which  software  can  be  generated  automatically. 

•  Reuse.  Constructing  software  from  existing  components  reduces  effort  and  increases 
reliability,  two  of  the  great  software  engineering  problems.  This  seemingly  simple  panacea  is 
made  complex  by  the  difficulty  in  integrating  components  drawn  from  arbitrary  sources. 
Domain  engineering,  and  the  standardization  that  results  from  it,  greatly  increases  the  ability 
to  reuse  existing  software  components. 

Megaprogramming  stresses  engineering  concepts.  Much  of  its  power  comes  through  instituting 
standards — as  Section  3  mentioned,  other  disciplines  are  far  ahead  of  software  engineering  in  doing 
so.  The  analysis  of  similarities  during  domain  engineering  is,  in  effect,  specifying  standards  for  the 
domain:  standard  requirements  (what  is  common  to  all  problems  in  the  domain),  standard  designs 
(the  architecture  in  Unit  4  shows  what  is  standard  to  all  designs  in  the  domain),  and  standard 
implementations  (components  shared  among  all  robots  establish  standard  algorithms). 

4.23  PotsPEcnvES  on  Mexsaprogramming 

The  original  ARPA  definition  of  megaprogramming  stresses  the  product-line  approach  to  software 
development.  The  description  in  this  section  is  but  one  way  to  achieve  a  product  line.  It  is  based  on 
a  software  engineering  approached  called  Synthesis,  developed  by  the  Consortium.  Synthesis  has  been 
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used  successfully  on  several  industrial  projects.  More  information  is  available  in  the  Reuse-Driven 
Software  Processes  Guidebook  (Software  Productivity  Consortium  1993). 

Other  researchers  have  taken  a  different  approach  to  megaprogramming.  Space  limitations  preclude 
discussing  them  here  (see  STARS  [1992]). 

43  BENEnXS  OF  PRACTICING  MEGAPROGRAMMING 

Section  2.2  described  five  significant  software  development  problems.  Megaprogranuning  will  not 
always  solve  the  problems,  but  practicing  it  can  significantly  alleviate  many  or  all  of  them.  This  section 
explains  how  megaprogramming  helps  organizations  overcome  each  problem. 

•  Expressing  software  requirements.  Application  engineers  practicing  megaprogramming  have 
two  advantages.  First,  because  they  describe  a  problem  in  terms  of  how  it  differs  from  other 
problems  in  its  domain  (see  the  laboratory),  they  reuse  requirements  instead  of  having  to  write 
them  from  scratch.  They  have  fewer  choices  to  make  and,  thus,  are  less  likely  to  make  an  incor¬ 
rect  choice.  Second,  the  requirements  they  create  are  precise  enough  to  allow  rapid  prototyp¬ 
ing  (this  is  essentially  what  goes  on  in  the  course  laboratory:  the  students  create  and  execute 
a  rapid  prototype  of  the  robot’s  control  software).  This  means  the  application  engineers  can 
show  a  model  of  the  system  to  customers  at  the  time  the  requirements  are  written,  rather  than 
having  to  wait  until  after  the  system  is  implemented.  Customers  can  immediately  point  out 
deficiencies  and  misimderstandings.  Consider  Slide  1-6:  fixing  a  requirements  error  during 
testing  costs  four  times  as  much  as  fixing  it  during  requirements.  Practicing  megaprogramming 
helps  application  engineers  find  errors  during  requirements. 

•  FoUowing  a  software  devdopment  process.  Much  of  this  difficulty  stems  from  the  generality  of 
the  waterfall  software  development  process  so  widely  used  today.  This  process  gives  only  gen¬ 
eral  guidance  and  does  not  direct  the  day-to-day  activities.  The  reason  it  is  so  general  is  that 
adding  more  detail  requires  making  assumptions  about  the  type  of  software  being  devel¬ 
oped — ^in  other  words,  about  the  domain.  Domain  engineers  are  tasked  to  add  exactly  this  in¬ 
formation  to  the  process  they  create  for  application  engineers.  Application  engineers, 
therefore,  have  a  very  detailed  process  to  follow. 

•  Keeping  requirements  and  documentation  up  to  date.  This  problem  often  arises  not  so  much  from 
bad  intentions  as  from  neglect:  no  one  is  explicitly  tasked  to  do  the  job.  An  organization  that 
practices  megaprogramt?-  ;ig  explidtly  recognizes  the  need  to  keep  requirements  and  docu¬ 
mentation  consistent  with  code.  Domain  engineers  are  responsible  for  developing  and  main¬ 
taining  standards  for  the  domain.  This  includes  documenting  the  standards  and  keeping  them 
up  to  date. 

•  Grasping  software  design.  Megaprogramming  helps  here  placing  the  design  in  a 
domain-specific  context.  Often,  understanding  a  design  is  simply  a  matter  of  evolving  a 
standard,  common  terminology  and  set  of  descriptive  techniques.  These  tend  to  be  a  natural 
by-product  of  multiple  iterations  of  domain  analysis. 

•  Resistii^  change.  Much  of  the  strategy  in  domain  engineering  involves  planning  for  change, 
attempting  to  anticipate  and  soften  its  effects.  Of  course,  industry  must  be  prepared  to  adopt 
megaprogramming,  which  is  in  itself  a  major  change.  However,  organizations  that  have  tried 
and  stuck  with  it  report  improved  productivity  (O’Connor  et  al.  1994). 


5.  THE  NEED  FOR  MEGAPROGRAMMING  IN 
HIGH  SCHOOLS  AND  UNIVERSITIES 


The  previous  sections  have  shown  megaprogramming’s  potential  importance  as  an  industrial  software 
development  approach.  Industrial  practices  are  not  necessarily  suited  to  classroom  settings,  however. 
Many  megaprogramming  details  are  relevant  to  a  large  corporation  but  not  in  a  classroom.  These  de¬ 
tails  arise  because  corporations  engage  in  huge  multiyear  projects,  which  are  simply  not  practical  for 
students. 

Nevertheless,  the  Megaprogramming  Curriculum  Project  believes  teachers  should  introduce 
megaprogramming  into  their  courses.  This  section  will  explain  why. 

5.1  THE  CURRENT  CURRICULUM:  STRENGTHS  AND  WEAKNESSES 

Section  1.1  discussed  the  current  computer  science  curriculum  briefly.  Understanding 
megaprogramming’s  importance  in  academia  requires  a  more  thorough  analysis. 

The  discussion  that  follows  concentrates  on  the  first  computing  course.  This  course’s  content  sets  the 
stage  for  students’  remaining  education  in  computing  and  therefore  plays  a  fundamental  r61e.  Subse¬ 
quent  courses — data  structures,  operating  systems,  etc. — build  on  its  content.  Changing  it  necessitates 
changing  the  rest  of  the  curriculum.  It  therefore  deserves  special  study. 

A  survey  of  model  curricula  (Larson  and  Stehlik  1990;  Thcker  et  al.  1991;  Merritt  et  al.  1993)  shows 
that  the  first  course  emphasizes  the  following  topics: 

•  Programming  Langiu^e  Notation,  lb  write  a  program,  a  student  must  master  the  nuances  of  a 
programming  language’s  syntax  and  must  feel  comfortable  expressing  algorithms  using  that 
syntax. 

•  Algorithms.  A  student  learns  sequencing,  conditional  execution,  and  iteration  very  early  in  the 
course — ^sometimes  within  the  first  two  weeks,  if  teachers  are  using  a  special  language  such 
as  Karel  the  Robot.  A  student  spends  much  of  her  or  his  first  year  learning  specific  algorithms 
to  be  used  in  conjunction  with  recently  introduced  language  features.  For  example,  many 
teachers  introduce  sorting  algorithms  almost  as  soon  as  they  introduce  arrays. 

•  Data  Structures.  A  student  learns  about  arrays,  records,  pointers  (less  frequently),  and  how  to 
use  them  to  create  certain  simple  abstract  structures,  such  as  trees  or  stacks. 

•  Programming  Methodology.  A  student  learns  approaches  to  software  specification,  design,  and 
verification.  The  coverage  of  specification  is  necessarily  brief  because  students  lack  the 
mathematical  background  necessary  to  grasp  most  specification  techniques.  The  emphasis 
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during  design  is  on  topnlown  decomposition  methods,  such  as  structured  programming  and 
information  hiding.  During  verification,  students  learn  testing  techniques  and  an  informal 
version  of  axiomatic  verification. 

This  emphasis  on  programming  methodology  does  not  extend  to  teaching  software  process 
concepts,  despite  the  obvious  overlap.  Several  of  the  model  curricula  present  software  design 
concepts,  but  none  expect  students  to  separate  design  fi'om  implementation. 

These  topics,  as  Section  1.1  mentioned,  have  formed  the  basis  of  the  introductory  computing  course 
almost  from  the  very  beginning.  Tb  be  sure,  the  course’s  content  has  not  been  static.  Context-fi-ee 
grammars  let  teachers  explain  syntax  quiddy  and  precisely.  Algorithms  were  once  presented  as 
flowcharts  (the  effect  of  which  was  mainly  to  make  students  grasp  a  second  notation);  now  teachers 
use  structured  programming  concepts.  Programming  methodology  is  now  understood  much  better: 
teachers  can  show  how  stepwise  refinement  leads  from  requirements  to  a  workable  design. 

The  Megaprogramming  Curriculum  Project  believes  these  topics  are  still  valid — writing  software 
requires  mastering  a  formal  notation  and  using  it  to  express  algorithms.  However,  the  project 
questions  the  emphasis  placed  on  them,  as  opposed  to  certain  other  topics,  and  the  manner  in  which 
they  are  introduced. 

Paradoxically,  the  reasons  why  stem  in  part  from  the  course’s  strength:  students  who  take  it  are  able 
to  write  simple  programs  in  an  arbitrary  application  area.  This  is  an  excellent  model  for  a  high  school 
or  university.  Instructors  in  areas  like  chemistry,  physics,  or  civil  engineering— not  to  mention  com¬ 
puter  science — can  assign  their  students  computationally  intensive  problems  after  the  students  have 
had  only  a  single  course  in  computing.  Indeed,  the  student  who  knows  sequencing,  conditional  execu¬ 
tion,  and  iteration  can  construa  an  algorithm  to  solve  any  solvable  problem— a  well-known  theoreti¬ 
cal  result  in  computer  science  (Bdhm  and  Jacopini  1966).  Few  other  disciplines  offer  such  a  general 
and  powerful  introductory  course! 

This  generality  comes  at  a  price.  Students  completing  the  first  a'urse  have  the  following  perspective: 

•  They  place  too  much  emphasis  on  the  programming  language  they  have  learned.  This  is  a  natural 
consequence  c:  their  struggle  to  learn  a  new  notation.  A  language  like  Pascal  has  a  complex, 
unforgiving  ^tax.  One  of  their  first  major  problems  is  learning  that  syntax,  so  they  attach  im¬ 
portance  to  the  language  syntax  rather  than  the  semantics — that  is,  the  ease  of  expressing  algo¬ 
rithms  in  it.  contrast,  the  skilled  software  developer  can  learn  the  syntax  of  any 
programming  language  in  a  day  or  two. 

•  They  think  of  a  program  as  an  a^rithm.  Experienced  software  developers,  however,  realize 
that  a  program  consists  of  a  set  of  modules.  They  use  modules  as  the  basis  for  contemplating 
and  expressing  software  design;  designs  of  programs  based  on  algorithms  have  not  proven  sat¬ 
isfactory.  Because  engineering  is  not  possible  without  a  design,  software  development  without 
a  design  wiil  never  be  a  disciplined  activity. 

■  They  think  of  software  development  as  consistii^  of  coding  and  testing.  This  paper  has  discussed 
the  steps  of  real  software  development  in  depth  and  has  shown  them  to  be  far  more  complex 
than  just  these  two  steps.  Experienced  software  developers  see  coding  as  a  largely  rote  activity 
that  follows  design.  Furthermore,  perceiving  the  cyclic  nature  of  software  development, 
developers  recognize  maintenance  and  the  problems  it  causes  and  try  to  plan  for  it. 
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•  Th^  lack  a  xi^fie  basis  to  a/uUyze  the  scfiwart  they  produce.  Most  high  schools  and  universities 
teach  a  course  called  “Introduction  to  Computer  Science,"  but  they  teach  little  or  no  science 
during  the  course.  Roughly  speaking,  computer  science  enables  someone  to  assess  the  quality 
of  a  computer  program.  Here,  quality  can  be  defined  in  terms  of  many  factors:  execution 
speed,  memory  use,  user  interface  friendliness,  reusability,  and  degree  of  fidelity  to  the  re¬ 
quirements,  to  name  a  few  measures.  Most  introductory  courses  only  teach  students  to  test 
their  software,  and  not  in  any  systematic  way.  Other  issues  are  ignor^.  Most  students  never 
practice  a  disciplined,  scientific  approach  to  software  development.  Experienced  software  de¬ 
velopers  try  to  be  as  disciplined  as  they  can,  scientifically  analyzing  their  software  design  (not 
implementation}. 

This  discussion  should  not  be  taken  to  mean  that  the  current  content  of  introductory  courses  is  easy. 
Formal  syntax  concepts  and  algorithmic  problem-solving  are  difficult  skills  and  require  time  to  mas¬ 
ter.  The  difficulty  is  making  sure  that  students  do  not  see  these  as  the  only  obstacles  to  writing  soft¬ 
ware,  or  even  the  main  obstacles.  People  with  this  perspective  grasp  only  a  small  part  of  what  software 
development  is  all  about  and  require  extensive  retraining  to  be  successful  in  the  work  force. 

Even  given  these  problems,  it’s  worth  questioning  whether  to  make  any  changes  to  a  curriculum  that 
does  a  generally  good  job  of  serving  the  community.  The  Megaprogramming  Curriculum  Project  be¬ 
lieves  that  the  current  model  has  its  place,  but  mainly  for  a  service  course.  Those  students  who  intend 
to  become  professional  software  developers  (or  even  computer  science  researchers)  would  benefit 
from  a  curriculum  that  teaches  more  about  how  software  is  actually  developed. 

5.2  BENEFITS  OF  MEGAPROGRAMMING  FOR  STUDENTS 

The  Megaprogramming  Curriculum  Project  believes  students  will  benefit  from  learning 
megaprogramming  in  four  ways: 

•  They  will  learn  to  see  software  development  as  an  exercise  in  science  and  engineering.  This 
paper  has  shown  how  megaprogramming  fosters  a  disciplined  approach  to  software  develop¬ 
ment.  Students  who  learn  megaprogramming  will  be  able  to  produce  better  software — and  will 
be  able  to  back  up  claims  of  quality. 

•  They  will  be  able  to  woi  k  ijn  more  complex  systems.  Megaprogramming  encourages  reuse,  so 
students  can  reuse  existing  software  that  performs  complex  functions.  The  laboratory  in  the 
Overview  Megaprm^amnmg  Course  demonstrates  this  point.  Students  create  reasonably 
complex  robot  control  software  by  reusing  existing  software  components.  Examples  of  this  na¬ 
ture  are  more  exciting  than  typical  student  projects;  as  a  result,  students’  motivation  will  be 
increased. 

•  They  will  learn  more  about  what  software  development  is  really  like.  This  makes  them  better 
prepared  for  their  careers. 

■  Their  perspective  toward  software  development  will  be  holistic.  Megaprogramming 
encompasses  all  aspects  of  software  development.  The  instructor  can  introduce  any 
software-related  topics,  and  can  tie  them  together.  Most  schools  teach  at  least  some  software 
engineering  topics,  (e.g.,  programming  methodology,  as  discussed  in  Section  S.l)  but,  lacking 
a  complete  approach  such  as  megaprogramming,  do  not  let  students  understand  the  full 
importance  of  the  topics. 
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S3  WHY  IN  THE  HRST  COURSE? 

Many  undergraduate  institutions  teach  inegaprogranuning  concepts.  Students  often  take  a  software 
engineering  course  in  their  third  or  fourth  year  and  learn  about  so^are  processes,  software  architec¬ 
ture,  etc.  The  Megaprogramming  Curriculum  Project  believes  that  these  concepts  should  be 
introduced  in  the  first  course,  even  in  high  schools.  Is  this  really  the  correct  place  for  them? 

A  survey  of  recent  conferences  in  software  engineering  education  (e.g.,  Diaz-Herrera  1994)  shows  a 
trend  toward  teaching  software  engineering  concepts  earlier.  Educators  complain  that,  in  the  current 
curriculum,  students*  early  education  appears  to  stress  the  wrong  skills.  Their  abstraction  abilities — ^so 
crucial  to  expressing  and  communicating  spedfication  and  design  concepts — are  poorly  developed. 
Their  software  development  techniques  are  not  suited  to  real  projects.  As  a  result,  one  of  the  software 
engineering  course’s  major  goals  is  to  make  students  forget  the  improper  skills  they  have  acquired. 

Some  secondary  considerations  support  introducing  megaprogramming  early.  Interest  in  computer 
sdence  as  a  major  dropped  considerably  during  the  past  decade  (Cries  and  Marsh  1989).  One  solution 
to  this  is  to  provide  students  with  more  interesting  problems.  As  discussed  in  Section  S.2, 
megaprogramming  inaeases  the  size  and  complexity  of  the  software  students  can  be  expected  to 
create. 

The  Megaprogramming  Curriculum  Project  may  also  been  seen  as  an  experiment  in  finding  the 
correct  amount  of  theory  to  introduce  in  the  first  course.  Computer  science  educators  have  always 
been  interested  in  this.  The  University  of  Maryland  is  a  noteworthy  example  (Mills  et  al.  1989).  Their 
first  course  introduces  students  to  the  more  mathematically  oriented  aspects  of  computer  science  and 
software  engineering,  such  as  axiomatic  program  definition  and  formal  program  verification. 

The  Megaprogramming  Curriculum  Project  is  striking  a  balance  between  this  extreme  and  the 
mainstream  approach.  In  megaprogramming,  the  science  comes  more  from  the  application  domain 
than  from  the  pure  mathematics  associated  with  computer  science.  The  student  therefore  learns  to 
see  rigorous,  quantitative  analysis  as  a  natural  part  of  software  development.  However,  the  student 
needs  no  special  mathematical  btu^kground. 

5.4  BENEnTS  OF  TEACHING  THE  OVERVIEW  OF  MEGAPROGRAMMING  COURSE 

Now  that  the  benefits  to  the  students  have  been  explained,  it  remains  to  discuss  what  the  instruaor 
may  expect  from  teaching  the  Overview  of  Megaprogramming  Course.  This  course,  as  the  name  implies, 
is  not  a  complete  course  in  megaprogramming.  After  taking  the  course,  the  student; 

•  Is  an  application  engineer,  for  the  domain  of  robot  control  software 

•  Has  an  appredation  of  the  important  issues  in  industrial  software  development 

•  Has  learned  the  concepts  of  megaprogramming,  a  new  and  exciting  approach  to  developing 
software 

These  concepts  include  application  engineering  and  domain  engineering.  The  course  teaches  the 
student  how  to  perform  application  engineering  in  a  particular  domain.  It  deliberately  omits  any 
discussion  of  how  to  perform  domain  engineering.  This  complex  topic  is  beyond  the  scope  of  an 
overview  course.  (The  Megaprogramming  Curriculum  Project  hopes  to  create,  or  encourage 


38 


5.  TV  Need  for  Megaprogramaung  in  High  Scfaoob  and  Universiiiet 


instructors  to  develop,  subsequent  course  units  that  will  teach  students  how  to  perform  domain 
engineering.) 

Despite  the  course’s  brevity,  the  instructor  who  teaches  the  course  should  Hnd  that  her  or  his  students 
have  a  more  realistic  understanding  of  the  role  software  plays  in  complex  systems  and  of  the 
difficulties  in  developing  it.  By  using  a  hypothetical  company,  and  by  providing  considerable  detail  on 
that  company,  the  course  tries  to  show  all  of  the  major  considerations  that  influence  software.  Often, 
these  considerations  are  not  technical  but,  as  the  laboratory  shows,  economic.  Nor  do  they  always  have 
obvious,  clearly  defined  answers.  Software  practitioners  must  be  able  to  justify  their  decisions.  The 
Overview  of  Megaprogramming  Course  provides  exercises  to  help  them  realize  this. 

The  Megaprogramming  Curriculum  Ih’oject  also  hopes  that  teaching  the  course  will  help  instructors 
become  more  aware  of  the  states  of  the  art  and  practice  in  industry.  The  course,  including  this 
document,  serves  as  a  sort  of  liaison  between  industry  and  academia. 

Teachers  who  have  taught  the  course  have  reacted  positively  toward  it.  Some  have  begun  to 
incorporate  its  concepts  into  their  regular  materials.  The  Megaprogramming  Curriculum  Project  is 
pleased  by  this  initiative,  for  it  shows  that  the  teachers  consider  the  material  valuable  and  a 
fundamental  part  of  a  student’s  education.  The  project  hopes  that,  through  actions  such  as  this, 
megaprogramming  materials  will  continue  to  influence  the  computing  curriculum. 
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APPENDIX  A.  RELATION  OF  LECTURE  SLIDES 
TO  Tins  REPORT 

This  report  makes  many  references  to  slides  from  the  lectures.  Someone  preparing  to  lecture  on  this 
material  may  appreciate  inverse  references;  which  sections  of  this  reptort  explain  the  material  of  a 
given  slide.  Thble  1  presents  that  information. 

Table  1.  Mapping  of  Slides  to  Sections  in  This  Report 
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APPENDIX  B.  STRUCTURE  OF  THE  OVERVIEW  OF 
MEGAPROGRAMMING  COURSE 


The  Overview  of  Megaprogramming  Course  is  organized  into  four  units  and  takes  approximately  1  to 
2  weeks  to  cover.  This  appendix  briefly  describes  each  unit. 

B.1  UNIT  1:  SOFTWARE  DEVELOPMENT 

The  first  unit  discusses  how  today’s  companies  develop  software.  It  shows  data  that  justifies  the  points 
it  makes  about  what  software  development  is  really  like.  It  covers  important  software  development 
concepts,  mainly  process  and  requirements. 

This  unit  uses  the  concepts  of  process  and  requirements  to  motivate  the  need  for  reuse  and 
megaprogramming.  A  simple  chart  of  the  megaprogramming  process  helps  students  to  put  the  rest 
of  the  course  in  the  proper  context.  An  in-class  exercise  asks  the  students  to  try  writing  complete  re¬ 
quirements  for  simple,  everyday  problems,  thereby  showing  them  how  difficult  the  requirements  step 
is.  This  unit  introduces  the  vending  machine  example,  which  will  be  used  throughout  the  course.  For 
their  homework  assignment,  the  students  devise  a  set  of  requirements  for  the  vending  machine. 

B.2  UNIT  2:  CONCEPTS  OF  MEGAPROGRAMMING 

Unit  1  covered  general  software  development  concepts.  This  unit  introduces  concepts  specific  to 
megaprogramming. 

It  presents  software  development  as  a  process  of  analyzing  a  problem  and  implementing  a  solution. 
It  then  defines  domains,  shows  how  domains  support  reuse,  and  discusses  domain  engineering  and 
application  engineering.  In-class  exercises  for  this  unit  have  the  students  identify  whether  or  not 
simple,  everyday  classes  of  applications  are  domains.  For  the  vending  machine  problem,  the  students 
combine  their  requirements,  identify  similarities  and  differences  among  their  different  vending 
machines,  and  identify  those  components  that  can  work  for  all  vending  machines.  For  homework, 
students  identify  what  components  they  need  for  their  own  vending  machine. 

B  J  UNIT  3:  APPLICATION  ENGINEERING 

This  unit  shows  students  what  software  development  is  like  when  using  megaprogramming.  The  unit 
introduces  problems  associated  with  robot  control  software.  Students  learn  how  megaprogramming 
helps  them  produce  such  software. 

At  the  end  of  this  unit,  the  students  are  given  a  laboratory  exercise.  They  must  carry  out  application 
engineering  in  the  robot  control  software  domain.  They  are  taught  about  URW,  the  hypothetical 
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company  from  Section  2.  The  students  build  the  software  for  three  customers:  a  farmer  who  needs 
corn  harvested,  a  representative  from  the  Alaska  National  Guard  who  wants  search-and-rescue 
robots,  and  a  National  Park  Service  ranger  who  wants  robots  that  can  pick  up  litter.  The  application 
engineering  process  the  students  follow  shows  them  the  commonalities  among  the  software 
requirements  for  these  seemingly  disparate  robots — although  it  also  calls  their  attention  to  the 
specific  differences.  The  software  solutions  they  generate  are  constructed  purely  from  reusable 
components.  They  integrate  these  components  according  to  a  domain-specific  software  architecture 
and  can,  therefore,  see  the  similarities  and  differences  among  implementations  as  well.  Robots  in  this 
domain  are  all  similar  in  that  they  search  autonomously  for  some  type  of  object.  However,  they  differ 
based  on  such  characteristics  as  the  terrain  they  search  (field,  tundra,  or  forest),  the  types  of  objects 
for  which  they  search  (corn,  people,  or  litter),  the  actions  they  take  on  finding  an  object  (pick  up  and 
return,  locate  only,  continue  indefinitely),  their  search  strategy  (zigzag  or  sweep),  and  their  initial 
amount  of  energy  (in  joules).  The  application  engineering  process  asks  the  students  to  reason  about 
robots  in  terms  of  these  concepts.  Students  must  also  make  quantitative  comparisons  of  robots  based 
on  a  cost  model  that  is  provided  and  an  execution  environment  that  simulates  the  time  and  energy 
needed  to  perform  a  mission.  Students  vary  certain  quantities  and  see  the  relative  effects  on  a  robot's 
cost  and  the  time  needed  to  complete  a  mission. 

The  laboratory  exercise  is  built  on  top  of  the  Karel-the-Robot  concepts  developed  by  Pattis  (1981). 
A  front  end  to  an  existing  Karel  implementation  asks  the  students  to  make  decisions  that  differentiate 
one  robot  from  other  robots  within  the  domain  as  described  in  the  previous  paragraphs.  Based  on  the 
decisions,  the  students  then  use  the  environment  to  generate  robot  software  from  the  reusable 
components  within  the  domain  and  to  simulate  the  robot  moving  through  the  specified  terrain 
performing  the  specified  mission. 

B.4  UNIT  4;  DOMAIN  ENGINEERING 

This  unit  discusses  what  a  company  must  do  to  achieve  the  software  development  capability  the 
students  saw  in  Unit  3,  defining  this  as  domain  engineering.  Because  of  time  constraints,  the  unit 
covers  what  but  not  how. 

The  unit  covers  the  information  domain  engineers  use  to  define  a  domain  and  aspects  of  the  suppiort 
domain  engineers  provide  for  the  application  engineer.  The  exercise  for  this  unit  helps  the  students 
see  how  they  can  use  megaprogramming  in  the  development  of  vending  machines.  An  examination 
evaluates  their  mastery  of  the  material. 


LIST  OF  ABBREVUTIONS  AND  ACRONYMS 

ARPA 
NASA 
URW 


Advanci-  Research  Projects  Agency 
National  Aeronautics  and  Space  Adm’aistration 
United  Robot  Workers,  Inc. 
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